Re: [Boost-build] [boost] [1.35.0] Threads - build failure using gcc on Win XP

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2008-04-21 07:40:25

Vladimir Prus wrote:
> Hmm, having glanced on this entire thread, I suspect we need to start from square one.
> Roland, Anthony, can you describe what exact behaviour you want for building of
> Boost.Threads?

Ok, I'll try to give a summary, and hopefully will be able to
explain why some users might experience something like breakage,
compared to the previous version 1.3.4.1.

In 1.3.4.1 there was one set of source files bb needed to
consider. The choice of actual platform was delegated to the
compiler. The target API was determined by compiler macros.

For two reasons we wanted to change that:

1) Cleaner code, i.e. no complicated #fdef paths in the
   source.

2) Ability to create two libraries, one for native API and
   one based on pthread API.

The include headers now are in api separated subdirectories,
and on central config switches in the correct one at compile
time. The mapping still is done by means of macros that
determine the platform.

The situation is different for source, as now there are separate
sources that need to be compiled. Of course it would have been
possible to engage a similar mechansim as for headers, but I
opted to hand this over to bb.

Consequently bb need to find the correct set of source files.

My intent was, that the user being able to request the threading
API to use by specifying a feature, i.e. <threadapi>

This brings up the question of what is default, if nothing
was explicitly requested. Also, to avoid the duplicate
target error for installation it is necessary to change the
tagging of the generated lib. Since I wanted to break as little
as possible I tagged the "default" library as before, and added
the "_pthread" tag to non-native builds.
E.g. on windows both libraries are possible at the same time,
i.e. libboost_thread and libboost_thread_pthread.

I based the notion of "default" upon what bjam gives for the
OS. This works for most cases, but fails in the case Mat run
against. Indeed it should be the compiler who decides what
default is, else the header macros and compilation of sources
will get out of sync.

The solution to this would be to condition threadapi on the
compiler used. Unfortunately this is not possible to do in
a robust way. All that a project can do, is to condition on
a <toolset-gcc:version>. Since the version is under user
control, i.e. what the user specified in unser-config.jam
the choice of threadpi would depend on this.

Another option would be to condition on <toolset-gcc:flavor>.
This solution would partly work, but has a serious short-coming.
If multiple versions of the compiler are set up in user-config.jam
and the user does not explicitely request the flavor on the
command line, the default flavor will be choosen, i.e. the
flavor of the first compiler. This is most likely not what
the user expects (and also is wrong).

To get the last issue straight the following would be
needed in addition:
toolset.add-requirements
<toolset-gcc:version>$(version):<toolset-gcc:flavor>$(flavor)

And, every other gcc also _need_ to get a flavor.

My proposal would be, to extend the flavor's meaning to
something more useful, e.g. setting flavor to the value
of gcc's -dumpmachine.

This would make it possible to uniquely condition on a specific
compiler, which also should turn out useful in cross compilation
setups.

Roland

-- 
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz_at_[hidden]
________| http://www.blackspace.at