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

Subject: Re: [boost] [tr1] Help needed with Darwin port
From: Stuart A. Malone (samalone_at_[hidden])
Date: 2009-01-13 12:50:17

On Jan 13, 2009, at 11:46 AM, John Maddock wrote:

> * Do people commonly install Boost into a system path such as /usr/ 
> include or /usr/local/include ?

I don't know about others, but my own Boost headers are currently  
installed in /usr/local/include/boost-1_37, which I explicitly add to  
the system header search path using the -I option to gcc in my project  
settings.

Before that, I had them checked into my Subversion repository so that  
each version of my project was paired with the version of Boost used  
to build it.  Under that scheme, there was no version of Boost  
"installed" at all, just local copies used for particular projects.

I don't think you can assume that any particular relative path will  
get you reliably from a Boost header file to a system header file.

> * Is it possible to detect the Darwin version number (to separate  
> 10.0 from 9.x)?

A quick find/grep through the system headers did not come up with  
anything obvious.

I would not attempt to detect the version using a shell variable like  
OSTYPE, though, since that would presumably detect the version of  
Darwin that you are running on, not the version that you are compiling  
for.  It's possible to have multiple versions of Apple's developer  
tools installed, and each one of them can support SDKs from older  
systems, so the version of Darwin that's running would not be a  
reliable indicator of where the stdc++ headers are stored.

> * Do you know what happens if someone installs gcc from source (ie  
> not from Apples developer tools)?

It's been some time since I've done this, but my recollection is that  
by default, the stdc++ headers that come with gcc get installed into a  
deep, deep subdirectory of /usr/local whose location is known only to  
gcc.  This is done so you have have multiple versions of gcc and stdc+ 
+ installed simultaneously.

I think that perhaps there's another way out of this situation.

I'm assuming that the reason you can't simply #include <iostream> is  
that you are defining a header whose name is also <iostream>, and  
attempting to include the stdc++ version of the header simply leads to  
infinite recursion.

I believe that gcc has a non-standard extension called #include_next  
that is designed to handle exactly this situation.  It includes  
another file, but searches for it _only_ in the directories that come  
later in the search path than the current directory.  You can read  
more about it at:

        http://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html

It appears that this feature has been part of gcc since at least 4.0,  
so you should be able to detect that version of gcc and then use that  
extension.

--Stuart