Re: [Texmacs-dev] Current work, nogencc and tree in generic programming

[Joris van der Hoeven]

> > This is not very logical
> 
> That is indeed a bit dirty. The problem is that it uses gmake features 
> for automatic dependences resolution.
> 
> The gmake info documentation (node: How Makefiles Are Remade) says:
> 
>     To this end, after reading in all makefiles, `make' will consider
>     each as a goal target and attempt to update it.
> 
> When first compiling from a clean distribution, the .d files are not 
> present, so the first pass inclusion fails, and then the .d files are 
> made.
> 
> I will fix that by defining a "deps" target to create the .d files, and 
> move the removal of those files (as well as the Objects/*.rpo files) in a 
> new "maintainer-clean" target.

I'll wait; it should be possible to fix such problems by
cleverly using makefiles.

> > 2. The compilation time is much longer than before, even though we only
> >    use -O2: this is bad.
> 
> That is true. That is a problem with the stupid automatic template 
> instanciation of g++2 (I do not know if g++3 is any smarter). A template 
> is instanciated (its code is generated) at the point where it is first 
> needed in a translation unit. This causes a lot of duplicate code 
> generation. At link time, the collect wrapper recompiles the units as 
> necessary until there is no duplicate code. The resulting information 
> about where templates must be instanciated is stored in the Objects/*.rpo 
> files, so subsequent compilations generate almost no duplicate code.
> 
> We can speed up the compilation by moving the removal of the .rpo files 
> to the maintainer-clean target.
> 
> We could also increase the size of the compilation units, by compiling 
> only .cc files containing only #include "xxx.cc" directives. However I 
> find this solution way too hackish because it make the .cc files

It is hackish, but it really speeds up compilation a lot.
So this solution should probably be preferred;
it was part of the .gen.make files before anyway.
I *want* TeXmacs to compile reasonably fast.