Greetings, and thanks for Automake.
We recently got bitten by what appears to be undocumented behavior in
AC_CONFIG_HEADERS (meaning that I couldn't find this behavior described in the
docs; I might well have missed it...?). It seems that AM's version of
AC_CONFIG_HEADERS automatically adds a -I to the generated file in the build
tree.
This caused a problem for us recently in a scenario like this:
AC_CONFIG_HEADER([include/hwloc/config.h])
This particular config.h is not our first AC_CONFIG_HEADER, so it is not
generated by Autoheader. It is actually a hand-crafted config.h.in file that
reflects only the configure-generated values that we need to be public (i.e.,
this file is installed). It is included by our top-level public header file
(hwloc.h) via #include "hwloc/config.h".
Perfect; it works great.
The problem came recently when we added some other files in include/hwloc/*.h.
One of them had the same name as a system header file -- something like this:
include/hwloc.h
include/hwloc/config.h <-- generated
include/hwloc/conflicting-name.h <-- /usr/include/conflicting-name.h also
exists
Some of the source files in our project have #include "conflicting-name.h" --
intending to get the system version. But since Automake hard-codes
-I$(top_builddir)/include/hwloc into Makefile.am, our source files are picking
up include/hwloc/conflicting-name.h, not the system version. Changing the
source files to #include <conflicting-name.h> doesn't seem to help. And since
the value is hard-coded in Makefile.am, we can't add any m4/shell scripting in
configure.ac to filter that -I value out.
I see the "nostdinc" Automake flag to inhibit adding all -I's, but that seems
like a bit of overkill for our needs. We *do* want the -I's for the
AH-generated file, but not for any others. Is there a way to do that? Or is
there another way to inhibit specific -I's?
If you're still reading -- thanks! :-)
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
