Re: The build system

[Jordi Gutiérrez Hermoso]

2010/7/8 David Grundberg <address@hidden>:
> Jordi Gutiérrez Hermoso skrev:
>> I've always balked at autotools and have never managed to understand
>> it, despite a few half-hearted attempts. Today as I was using it to
>> develop on Octave I noticed that if I touched src/load-path.cc a
>> *massive* recompilation would take place. <snip>
>
> I ran touch src/load-path.cc && make.  It compiled load-path.cc and
> linked (no compilation) a lot of DLD-FUNCTIONS.

Just so we're all on the same page, I attach what I see when you do
that. Touching that file and rebuilding produces 194k of output.

It seems to also compile builtins.cc and yes, links tons of files. I
thought earlier it was compiling them too, oops, my mistake.

>> I wish we could use something else to build Octave, but I'm not sure
>> anything else can also handle the chore of compiling Octave. I know
>> autotools solves a problem that no other build system solves, namely,
>> maximum *nix portability. So before I go on another wild goose chase,
>> why does this happen? Is there a way to speed up development and avoid
>> large recompilations when touching just one source file?
>>
>
> Linking cascades.  I don't see how anything is wrong with autotools or
> how switching to another build system would fix that kind of problem.

So I probably don't understand libtool or how the DLD mechanism works,
but why does apparently every DLD function need a .so and why does
every .so need to be linked to the output of an unrelated function,
especially if those .so's aren't output targets? Also, why does
linking need compilation flags like -Wall or -O2? The former is just
harmless clutter, but the -O2 flag can really slow down linking. The
documentation for ld suggests only using it for the final binary,
which none of these are.

What I would expect: there are only three libraries that actually get
installed, and I believe only liboctinterp.so actually use the code of
src/load-path.cc, hence, one compilation, one linking, and since the
docs need to be regenerated, one pass at regenerating docs. Why isn't
this what happens?

Also, another bit of slowdown is that libtool is a shell script, so
each of those linkings is sloooooow because you need to run a large
shell script each time. That's one clear disadvantage of autotools,
slowness. How slow? This slow:

     address@hidden:~/coding/vcs/octave$ touch src/load-path.cc
     address@hidden:~/coding/vcs/octave$ time make > /dev/null

     real       1m19.113s
     user       0m57.512s
     sys        0m14.277s

Okay, maybe I'm a crybaby and this is a far cry from waiting in line
for a month for your FORTRAN punch cards to compile, but still, more
than one minute to be able to see the effects of changing one line in
one source file makes for sluggish development. Or maybe I should
acquire the fortitude of those FORTRAN programmers of yore and triple
check my code before sending it to compile?

build.gz
Description: GNU Zip compressed data