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