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