Subject: Re: [Boost-build] Default threading model in Linux
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2008-11-09 12:16:42
Vladimir Prus <ghost <at> cs.msu.su> writes:
> On Sunday 09 November 2008 19:16:39 Joaquin M Lopez Munoz wrote:
> > No, I'm referring to the threading model assumed when, for instance,
> > building a test with
> > test-suite "foo" : [ run foo.cpp ] ;
> > So, threading=single is assumed here, right?
> I don't understand what "assumed" means. When every target is built,
> all non-optional feature has a specific value -- there's nothing
> to "assume". Unless you did something to force MT, threading=single
> will be in effect.
Here, by "assumed" I meant "by default". So, threading=single
is the default unless otherwise specified.
> > That poses a
> > small problem, as on the other hand BOOST_HAS_THREADS and
> > BOOST_HAS_PTHREADS seem to be unconditionally defined,
> By what code? On gcc, those are set only if -pthread is added to gcc
> options during compilation.
Here's where my observations differ: I'm using gmane to write
this, so I can't attach files, the following are pasted inline:
test-suite "foo_test" : [ run foo.cpp ] ;
Put these two files under a folder foo in boost/libs and
play with bjam and different settings or threading:
GCC under Cygwin:
So, seems like these Boost.Config macros are not affected
by the threading model selected. I can't try on Linux (no
Linux box at hand right now) but some reports I received lead
me to believe the same problem will show, maybe some kind
reader can try these and tell us the results.
JoaquÃn M LÃ³pez MuÃ±oz
TelefÃ³nica, InvestigaciÃ³n y Desarrollo
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk