Re: [boost] [tr1] Help needed with Darwin port

Subject: Re: [boost] [tr1] Help needed with Darwin port
From: John Maddock (john_at_[hidden])
Date: 2009-01-14 11:49:14

> After reading your response and thinking about this problem a bit
> longer, I've come up with two other possible workarounds if the
> #include_next solution doesn't work.
>
>
> Solution 1.  Create a subdirectory called something like "bridges".
> For each stdc++ header that you need to include, create a bridge
> header in this subdirectory whose name is _not_ the same as the name
> of the original header.  It might look something like this:
>
> File <boost/tr1/iostream>:
>
> #include <boost/tr1/bridges/iostream-bridge.hpp>
>
> File <boost/tr1/bridges/iostream-bridge.hpp>:
>
> #include <iostream>
>
> I _think_ that the #include in the bridge header will reliably locate
> the original stdc++ <iostream> header, since there is no file named
> "iostream" in the current directory and the bridges directory is not
> on the search path.

No because we do have a Boost file called <iostream> in the include path, 
it's getting from there to the real <iostream> that's the hard part :-(

This does put in mind another possible solution though.. but it'll need a 
more or less complete rewrite of the forwarding code, so it'll have to wait 
for now.

> Solution 2.  Include some stdc++ header that is _not_ being redefined,
> and then use the value of __GLIBCXX__ to determine the path to the
> other headers.
>
> #if defined(__GLIBCXX__)
>   #if __GLIBCXX__ == 20050421
>     #include <c++/4.0.0/iostream>
>   #elif __GLIBCXX__ > 20050421
>     #include <c++/4.2.1/iostream>
>   #else
>     #error Unknown version of the GCC stdc++ library
>   #endif
> #endif

That might work, I'll give it a try.

> I certainly don't recommend this since it is so fragile, but a
> solution like this might work if nothing else does.  Let me know if
> you choose to go this route and I'll try to come up with the possible
> values of __GLIBCXX__ for you and the corresponding paths.

I think as long as we know the __GLIBCXX__ versions for which the path is 
"4.0.0", that should be enough, as the case where libstdc++ is correctly 
tied to the compiler version is already handled.

> I'd also be happy to do a few test builds for you once you think
> you've come up with a solution, since we do have a vested interest in
> this working correctly.  ;)

Can you try running the tests in Trunk now?  There will be some failures 
from the *tricky.cpp tests, but the others should all pass.

Thanks, John.