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 ha escrito:
Folks, I have a configuration problem I don't know how to solve, so I'm soliciting for ideas.
[...]
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 ! ;-)
Have you asked at the STLport developers list (http://sourceforge.net/forum/forum.php?forum_id=490892 )? They have long tackled the same problem and their expertise can help. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

Am Freitag, 07. September 2007 14:32:21 schrieb John Maddock:
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 :-(
Note that "giving up" would mean relying on distro maintainers that change the GCC include path to also patch boost in order to find these headers. As a side note from the one who reported the bug and already spent too much time thinking about it: I am using Gentoo, which already patches STLport to find the headers - citing from http://gentoo-portage.com/dev-libs/STLport:
src_compile() { cat <<- EOF >> stlport/stl/config/user_config.h #define _STLP_NATIVE_INCLUDE_PATH ../g++-v$(gcc-major-version) EOF
Alas, they do not do so for boost yet, which is why the following simple program does not compile on stock Gentoo with GCC 4.1.2 and boost-1.34.1 installed: #include <boost/tr1/tuple.hpp> int main() { return 0; } Greetings, Hans
participants (3)
-
Hans Meine
-
Joaquín Mª López Muñoz
-
John Maddock