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
to after all my 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
# 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: http://lists.boost.org/MailArchives/boost-users/msg02664.php. 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. HTH, Glen