Eric Blake wrote:
> But which order is preferred?
>
> The gnulib manual recommends:
> AM_CPPFLAGS = -I$(top_builddir)/lib -I$(top_srcdir)/lib
It is like this on purpose. As Mike has explained, there are situations
(which shouldn't occur but somehow do occur in rare cases) where the
.h file is left over in $(srcdir). Some of these situations arise through
the use of AC_CONFIG_LINKS and someone not doing "make distclean".
For gnulib generated .h files we made an effort to make things more robust
in April 2011 [1]. But it is nevertheless possible to break the thing
if people don't learn to do "make distclean". Therefore I'll continue
to recommend this order.
> But m4 is using the reverse order:
> AM_CPPFLAGS = -I$(top_srcdir)/lib -I../lib
I have never seen an argument in favour of this order.
> 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.
This scenario must be very rare, because
1. we are rarely removing complexity, therefore it is extremely
seldom that a generated file becomes an in-place distributed file,
2. people who use a VPATH build often throw away the entire build dir
anyway.
> 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.
This scenario is more frequent. In this case, when people forget to do
"make distclean" or had removed their gnulib-cache.m4 file, the file
would not be removed in srcdir. Therefore it _does_ matter to search
builddir before srcdir.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00045.html
