|
From: Dave G. <go...@mc...> - 2010-01-04 17:31:29
|
On Dec 31, 2009, at 7:32 AM, Bart Van Assche wrote: > On Thu, Dec 31, 2009 at 1:38 PM, Julian Seward <js...@ac...> > wrote: >> >> More seriously, it means that the installation tree (still) >> lacks a config.h which matches/describes how the installed >> libraries and executables were built. Perhaps a better solution >> would be to revert this and to install config.h too. > > Sorry Julian, but I disagree completely with the above. ... > Furthermore, exposing all symbols defined in Valgrind's "config.h" to > external projects would create a high probability of symbol collisions > / redefinitions, e.g. the HAVE_* macro's. The HAVE_* macros are usually the least of your problems, because they _usually_ are redefined to identical values, which is OK by the preprocessor. The most common show stoppers are PACKAGE, VERSION, etc that are practically guaranteed to have different values between two projects. The unmodified config.h is definitely not installable. > If we really have to expose some of the symbols defined during > Valgrind's configure process, we should do like Stefan Kost proposed > and let the configure process transform a file valgrind_config.h.in to > valgrind_config.h. That would allow us to export a minimum set of > symbols from Valgrind to external projects instead of all symbols > defined during the configure step. You may already be aware of this, but the AX_PREFIX_CONFIG_H macro was written so that you could safely install a namespaced version of the config.h if you need to: http://www.nongnu.org/autoconf-archive/ax_prefix_config_h.html It's a pretty heavy-handed solution though, and it might be worth the additional effort to generate a header containing only the minimum set of symbols instead. Which one makes more sense will depend on how large that minimal set is and how often it changes. -Dave |