Oracle recently pinged me with a problem in an OMPI build regarding the hwloc/myriexpress.h -- somehow #include "myriexpress.h" is picking up opal/mca/paffinity/hwloc/hwloc/include/hwloc/myriexpress.h instead of the system's myriexpress.h. This causes badness; see https://svn.open-mpi.org/trac/ompi/ticket/2690.
I tracked down why this was happening: automake is adding a -I to any directory where AC_CONFIG_HEADERS is used to generate a header file. Since we're generating include/hwloc/config.h (i.e., the publicly-includable config.h file that is included by include/hwloc.h), automake is adding -I$(top_builddir)/include/hwloc.
For VPATH builds, this clearly isn't a problem (because it's relative to the build tree, not the source tree). But for non-VPATH builds, #include ordering can (and does) get wonked.
Unfortunately, the -I is added by Automake in a place where we can't simply filter it out with some m4 / shell scripting. Specifically: it's hard-coded directly into Makefile.in -- before configure is run.
Possible solutions:
1. We can use Automake's "nostdinc" flag to suppress this add-the-dash-I behavior.
PRO: extra -I goes away
CON: we have to manually add a -I for other AC_CONFIG_HEADERS
CON: doesn't solve the issue for embedding (*** this is a deal breaker)
2. Rename myriexpress.h
PRO: avoids the problem
CON: breaks legacy apps who include "hwloc/myriexpress.h"
CON: doesn't solve the real problem
3. Move hwloc's public config.h in a new directory by itself (e.g., include/hwloc/config/config.h)
PRO: works around the AM behavior
PRO: fixes the issue for hwloc and for embedding
PRO: avoids any other name potential conflicts with include/hwloc/*.h
CON: kludgey -- leaves a bitter taste in your mouth
4. Don't use AC_CONFIG_HEADER (i.e., use sed+friends to generate include/hwloc/config.h ourselves)
PRO: avoids the problem
PRO: fixes the issue for hwloc and for embedding
PRO: avoids any other name potential conflicts with include/hwloc/*.h
CON: I don't want to code that up :-)
It seems like #3 and #4 are the best solutions. I'm not excited about doing #4, so I'd prefer #3, even though it's a bit icky.
Any other suggestions?
--
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}