automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AC_CONFIG_HEADERS


From: Jeff Squyres
Subject: AC_CONFIG_HEADERS
Date: Thu, 3 Feb 2011 10:30:24 -0500

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
address@hidden
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]