|
From: Greg P. <gp...@ap...> - 2010-01-05 02:13:44
|
On Jan 4, 2010, at 9:31 AM, Dave Goodell wrote: > 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. Another problem with saving config.h: on platforms that support multiple CPU architectures on a single machine, there is no single config.h that will be correct for every architecture, even if you limit it to a single project. For example, if config.h records the pointer size then it can't work for both 32-bit and 64-bit builds. Mac OS X has lots of different architectures available on a single machine. autoconf-style projects are reconfigured and rebuilt separately for each architecture, and then the products of all builds are combined into a single universal binary. That way each architecture's build gets its own config.h. -- Greg Parker gp...@ap... Runtime Wrangler |