Re: building directly from $(top_builddir)

[Akim Demaille]

Le 18 juil. 09 à 18:06, Bruno Haible a écrit :

Hi Bruno!

Thank you for the attention you paid to my message!

> Eric Blake wrote:
> > gnulib-tool could make this part easier by automating it somehow (a  
> > new
> > command line option to state whether the gnulib.mk fragment will be  
> > used
> > in the current directory [default], or included from some other  
> > directory
> > where all relative paths need an extra prefix [as in bison's case]).
>
> Such a feature would require changes (to insert $prefix here and  
> there) in
> many places, i.e. in many module descriptions. That's hardly  
> maintainable
> (and rarely tested, since most gnulib users would not use this  
> feature).
>
> The alternative quite easy: Just include a tiny Makefile.am in the
> subdirectory, that does
>
>   include gnulib.mk
>
> and invoke that Makefile from the top-level directory, by use of
> AC_CONFIG_SUBDIRS.

Of course, but that's exactly what I departed from.  I actually
wrote a small post-processing tool that converts gnulib.mk into
one with the needed lib/ added here and there.

> Does bison have any specific problems following this approach that
> everyone else has used so far?

First of all, I'm not asking anything to the gnulib community, I
have the conversion tool, it does a reasonable job, and I can
live with it.  Of course if the feature is provided by gnulib
itself, that's better :)

The motivations are speed and accuracy.

After having used for years one Makefile.am per directory, I
started converting my projects to use fewer Makefile.am,
sometimes just a single one, using extensively "include
foo/local.mk" and so forth.

Since today there is no assistance from Automake, it is quite
unpleasant, as you need to add prefix a bit everywhere.  If some
patches of Ralf make it into a forthcoming release, then this
should be made easier and more consistent thanks to
meta-variables that expand to the current include-prefix.

But once this done, concurrent builds are much more efficient.
Not only because you expose more concurrency opportunity to Make,
but also because your dependencies are more accurate: instead of
relying on the ordering of SUBDIRS to go into lib/ before
compiling in src/, Make can see whether the library needs to be
updated or not.  And it turns out that, at least in some packages
I work on, it is not always needed.

The effect is even more striking when the test suite is itself
relying on the dependencies: running make check TESTS='...'  will
just compile what is needed, instead of recuring in a bazillon of
useless directories to see it has nothing to do.  Since my test
suites actually maintain some state, tests that were not updated
will not even be run.  This can be provide very large savings.

Finally, about accuracy.  I have been bitten sometimes because of
incomplete "bouncing" targets.  For instance Bison uses various
auxiliary tools to generate bits of its documentation (that lives
in doc/) from bison --help.  If you want to be able to trust
"make -C doc pdf" (even if "make" was not run beforehand), you
need a small fake target that runs "make -C ../src" when needed.
But then, what are the dependencies?  I used approximations,
which eventually bite you.  Now I don't need all this, I just
use "the real thing".


I'm not trying to convince here, just explaining why I prefer
this today.  Since I work on packages that embed others (and
quite deeply actually), everything that can be used to speed
things up is nice.

Of course there are several problems.  The one that annoys me the
most is the total lack of scoping in Makefiles, which becomes a
real problem when you want to play with various sets of *FLAGS.
So I use foo_CPPFLAGS, which, unfortunately causes Automake to
create adhoc rules for every single file, which results in
possibly extremely large Makefiles which Make takes quite long to
load...

I wish Automake had a "I *will* use GNU Make on the other side"
option.  Something that would help keeping the Makefiles smaller.

Cheers!