The manual (gnulib-tool.texi) recommends including both builddir and
srcdir into AM_CPPFLAGS (aka INCLUDES if you are using automake 1.9),
which makes sense, since some headers come straight from gnulib and live
in srcdir, while other headers are generated based on configure results
and thus live
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
On 02/02/2012 01:28 PM, Mike Frysinger wrote:
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
Eric Blake wrote:
The manual (gnulib-tool.texi) recommends including both builddir and
srcdir into AM_CPPFLAGS (aka INCLUDES if you are using automake 1.9),
which makes sense, since some headers come straight from gnulib and live
in srcdir, while other headers are generated based on configure
On 02/02/2012 01:43 PM, Jim Meyering wrote:
And coreutils has a bug, for forgetting the builddir version (which
means it will build in an in-tree build, but probably fail in a VPATH
build):
AM_CPPFLAGS = -I$(top_srcdir)/lib
forgetting? ;-) Nah.
On the contrary, I vaguely recall
On Thursday 02 February 2012 15:40:59 Eric Blake wrote:
Yes, hacks like that render the question of stale files moot. But
without resorting to sledge-hammers, can we come to a consensus on which
way things should listed be in a best-practices project?
i have my personal opinion, but i'm
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
