Re: [Boost-Users] [BUG] Macos.hpp configuration woes

From: Bobby Thomale (bobby-thomale_at_[hidden])
Date: 2002-10-24 09:53:39

Cool ... results ... :-)

I love how responsive the Boost community is.  Have I mentioned lately that
you guys rock?  I am replying to this whole thing at once.

Chris Little wrote:

> Change the line to
> 
> #if defined(__MACH__) && __MACH__
> 
> This was talked about in June on this list and I thought someone had
> submitted a patch but I guess not.  I'm still building CFM apps so I hadn't
> noticed.

Yep.  That was me, too, that started that discussion.  The original line was
#ifdef __MACH__.  I suggested the above, then someone else (Darin I think)
pointed out that #if __MACH__ does the same thing and is shorter.  :-)

#if __MACH__ is what it does now, that is equivalent to your above line.  So
that was a different problem which is solved.

(Looks like you guys already figured that out later in the discussion...)

Then Darin Adler wrote:

> OK, I'll be happy to fix this.

That's great.  Again, thanks for being so responsive guys!

>> There are also people who use other STL implementations, such as
>> STLPORT.
> 
> It doesn't really matter which STL implementation you are using. The
> stuff in macos.hpp is for the C standard library. MSL C, not MSL C++.
> The STL is part of the C++ library, and that's handled by msl.hpp, etc.
> While there may be a problem there, it's not the same one you mention
> above.

Sure.  I was just giving a for-instance, I am not actually using STLPORT or
know of any probs with it.  I think I understand what you are saying though.
In the "BOOST_STDLIB_CONFIG" macros and files, "STDLIB" means "The Standard
C++ Libraries (STL) only" and not "The Standard C/C++ Libraries."  Got it -
that wasn't obvious to me.

So if someone were using STLPORT, for instance, that doesn't replace your
standard C libs too - it is just a C++ STL implementation built on top of
whatever C libs you happen to be using?

Very interesting and cool.  My confusion was partly because I wasn't sure
what you guys meant by "STDLIB" and also because CW always tended to lump
the standard C libraries, and their C++ STL stuff all together into one big
set of libraries, and call it one name.

I haven't actually tried STLPORT or any of the other third party STL libs, I
was assuming they replaced all of your standard libraries, not just the C++
portion.  Now that I think about it, though, that'd require them to chase
platform changes, which would be abstracted for them by the C libraries.
The C libs tend to be a platform specific abstraction layer, which is why C
library stuff for Boost goes in a "platform" file not "STDLIB."

Got it.  Makes perfect sense now.  Thanks!

Later Darin wrote:

>> For CWP8 it looks like the line should be
>> 
>> #if __MACH__ && !defined(_MSL_USING_MSL_C)
> 
> That will work for CodeWarrior Pro 7 too, because _MSL_USING_MSL_C
> won't be defined under 7. I'll take care of it.

Sounds like a good fix.  I will get Jessica to try it out.  I'm sending it
to her now - it should do the trick.

>> I'm not sure what to do for CWP7 though.  Now that I'm running Jaguar
>> (and thus gcc 3.1) CWP7 can't even build a simple mach-o console app
>> due to conflicts in standard library headers.
> 
> Sure, that's a problem. It's too bad that CodeWarrior Pro 7 is not
> compatible with Jaguar. But nothing for Boost to worry about.

Yep - the MW party line on Jaguar problems is "Upgrade to CW Pro 8."

                                -- Bobby

---------------------------------------------------------------------
Bobby Thomale
Senior Software Developer
Inoveon Corporation
http://www.inoveon.com/
---------------------------------------------------------------------