Boost logo

Boost Users :

From: Glen Simmons (gsimmons_at_[hidden])
Date: 2004-10-12 08:45:17

On 9 Oct, 2004, at 1:03 PM, goochrules! wrote:

> I think I just ran into the same problem you did. I'm using
> boost::thread in a .mm file. Having seen problems with boost
> libraries and Cocoa before, specifically boost::spirit, I did what I
> did then, and moved the #import <Cocoa/Cocoa.h> to after all my
> <boost/...> includes, and the errors went away.
> Because of this I suspect there is a greater issue here with the boost
> and Cocoa headers that is not limited to spirit or thread.

 From a later message in this thread:

>>> OK, it turns out that BOOST_HAS_THREADS *was* getting enabled, but
>>> was later getting disabled in suffix.hpp because BOOST_HAS_PTHREADS
>>> was not enabled. I believe that it should be enabled by the
>>> inclusion of posix_features.hpp, but this is not happening because
>>> of this test in macos.hpp:
>>> # ifndef TARGET_CARBON
>>> # include <boost/config/posix_features.hpp>
>>> # endif
>>> I'm building a Cocoa project in Xcode, which apparently defines
>>> TARGET_CARBON for me. Why is posix_features.hpp only included if
>>> TARGET_CARBON is not defined? You can use posix from a carbon target
>>> just fine. Commenting out the #ifndef so posix_features.hpp is
>>> included makes it build and work just fine. Is there some reason for
>>> this that I'm not seeing? Is this a bug?
>> I don't know enough (well anything really!) about MacOS targets, and
>> what is and is not correct for them, searching the archives it
>> appears that I added this check after a user request:
>> Obviously we need a better way of doing things, so any suggestions
>> welcome...
> Ahh, that explains it. The problem is that testing for TARGET_CARBON
> is too broad for the issue that Mr. Thomale was having. I'm sure there
> are various macros defined by MSL that would be a better check. Or,
> (yet) another flag to set in user.hpp indicating that the user is
> using the MSL. Unfortunately, I am not familiar with MSL, so I can't
> suggest a fix. For now, I've removed the test for TARGET_CARBON, which
> solves my problem.

As stated above, I commented out the #ifndef TARGET_CARBON (and
corresponding #endif) in macos.hpp. If you take a look at the message
referenced above, the check was added in response to a user who was
having trouble integrating Boost & Metrowerks CodeWarrior. Since I'm
not using CodeWarrior, I feel safe in removing the check.


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at