Re: AM_CPPFLAGS best practice

[Mike Frysinger]

On Thursday 02 February 2012 15:10:11 Eric Blake wrote:
> Is there any specific reason that gnulib recommends builddir (generated
> files) before srcdir?

my gut tends to prefer builddir over srcdir.  but that could be due more to 
poorly managed packages than a "best practices" setup.  in cases where a 
header file is shipped as part of the distribution and is *usually* used, but 
could possibly be regenerated (and thus show up in the builddir), we'd want 
the builddir version over the srcdir one.

> Consider the ramifications if a file changes
> location.  If it goes from generated to in-place (moves from builddir to
> srcdir, because it no longer depends on configure results), then
> favoring builddir first means that in an incremental build where you
> forget to run 'make clean' before updating gnulib, the stale generated
> header will be left over in the build tree and be picked up in
> preference to the new gnulib file.  Conversely, if a header goes from
> in-place to generated, it will no longer live in srcdir, but only in
> builddir, so it doesn't matter whether you favor builddir or srcdir.
> Therefore, it seems to me that best practice would be to always favor
> srcdir first, builddir second.

it isn't uncommon (in my experience) for this to not be as clean as it should 
be.  consider people who have older gnulib in their pkg's tree, and then they 
update their gnulib checkout (which is located elsewhere), and then run 
gnulib-tool in their pkg to update things.  if a header went from non-
generated to generated, the older version isn't cleaned out automatically.  in 
general, gnulib does not seem to be that good at cleaning up its old stuff.

iirc, i hit this exact bug sometime ago with a project and reported it as a 
failing in gnulib, but upon debugging we found that i had a stale header in my 
srcdir that went from non-generated to generated and the -I paths picked up 
the old one.  i felt bad for wasting the gnulib peep's time (it might have 
even been you Eric :P).

it's also for this reason that in projects i manage, i try to make sure that 
*all* files coming from gnulib live in a dedicated dir.  that way my autogen.sh 
can just `rm -rf` it before running gnulib-tool.  the one or two files that 
gnulib likes to stick in the top-level dir anyways are annoying, but i can 
cope with that much better now that i have git.
-mike

signature.asc
Description: This is a digitally signed message part.