[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AM_CPPFLAGS best practice
From: |
Jim Meyering |
Subject: |
Re: AM_CPPFLAGS best practice |
Date: |
Thu, 02 Feb 2012 21:43:08 +0100 |
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 results
> and thus live in builddir. But which order is preferred?
>
> The gnulib manual recommends:
> AM_CPPFLAGS = -I$(top_builddir)/lib -I$(top_srcdir)/lib
>
> But m4 is using the reverse order:
> AM_CPPFLAGS = -I$(top_srcdir)/lib -I../lib
>
> 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 deliberately removing the
explicit (and then-redundant) -I... option back when I noticed
that automake handled that part for us.
In the case of coreutils, DEFAULT_INCLUDES covers that:
$ grep DEFAULT_INCLUDES.= src/Makefile
DEFAULT_INCLUDES = -I. -I$(top_builddir)/lib
>From what I recall, that's by virtue of our putting config.h in lib
via this line from configure.ac:
AC_CONFIG_HEADERS([lib/config.h:lib/config.hin])
Of course, if something uses $(AM_CPPFLAGS) without also
using $(DEFAULT_INCLUDES), then you'd have a point.