Ideas Wanted: How best to configure Boost.TR1 with GCC?
Folks, I have a configuration problem I don't know how to solve, so I'm soliciting for ideas. Here's the basic problem: Boost.TR1 has to replace some of the std library headers, and forward to the existing "real" ones. To do this it can either: 1) Use #include_next to forward to the real std lib header. 2) Use #include <../some_directory/header_name> to forward to the std lib header. Up until now, I've been using #1 with GCC, unfortunately if Boost is installed in /usr/include then it doesn't work: because the Boost include path appears *after* the std library one rather than before it. So... in response to a bug-report I recently changed it to method 2 (on Linux anyway), using the same configuration logic as STLport to determine what "some_directory" is called. Having tested it locally with several gcc versions on Linux everything seemed fine... except it's not: the problem is that gcc has a configuration option that lets you change the name of the directory the headers go in, and several Linux distro's change it from the default, so instead of being the normal default of something like "4.2.0" it's g++-v4 or something else that we can't automatically deduce :-( Obviously I could add a user-config macro for this purpose, but it's all a real pain basically :-( Anyone any better ideas? Or should I give up before I loose the will to live ! ;-) Thanks! John.
John Maddock
[...] Having tested it locally with several gcc versions on Linux everything seemed fine... except it's not: the problem is that gcc has a configuration option that lets you change the name of the directory the headers go in, and several Linux distro's change it from the default, so instead of being the normal default of something like "4.2.0" it's g++-v4 or something else that we can't automatically deduce
If you try this inside a MACRO I think you are lost. I'd propose a feature request for gcc to provide a predefined macro (http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html) As a workaround I'd use the runtime information from gcc itself to preconfigure the system: gcc -v yields the information about how gcc was configured, e.g.: Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) So I think that parsing this line for --prefix, --with-gxx-include-dir, --version-specific-runtime-libs etc. should give you any deviation from default paths. Together with the information about default paths for every release version of gcc you have all you need - but only outside a compilation run.
Obviously I could add a user-config macro for this purpose, but it's all a real pain basically
Yeah. Not much help from here ... Markus
participants (2)
-
John Maddock -
Markus Werle