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

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-04-17 21:21:05

On Mon, Apr 14, 2008 at 2:53 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
>
> Mat Marcus wrote:
> > On Mon, Apr 14, 2008 at 1:53 PM, Anthony Williams
> > <anthony_w.geo_at_[hidden]> wrote:
> >
> >> Oops. That should be a check on target-os. I don't know jamfile syntax well
> >> enough to fix that though --- I don't think <target-os> is available at that
> >> point.
> >>
> >> Anyway, that's the "default API" selection: threadapi=pthread can override
> >> that.
> >>
> >> So: can we try target-os=cygwin threadapi=pthread?
> >>
> >> Anthony
> >> --
> >
> > Thanks! That succeeds for now. Ok, so a followup question is, for my
> > (local) boost patch file, what modifications should I make? My goal is
> > to restore the state of affairs to that of 1.34.1: the user didn't
> > need to make any explicit mention of the threadapi or target-os on the
> > command line or in the user-config.jam. Or will I need patches to both
> > the boost thread Jamfile.v2 and the boost build system to restore
> > auto-detection?
>
> I'm sure we want auto-detection... But to make your immediate life
> easier you can add this to your user-config.jam:
>
> ====
> import toolset ;
> toolset.add-requirements
>   <toolset>gcc-4.2.0:<target-os>cygwin
>   <toolset>gcc-4.2.0:<threadapi>pthread ;
> ====

Now that I've managed to get a cygwin-built bjam up and running too on
my machine I'm faced with another issue. Here is a pared down version
of my current user-config.jam

import toolset ;

using msvc : 9.0 : "C:/Program Files/Microsoft Visual Studio
9.0/VC/bin/cl.exe" ;

toolset.add-requirements
  <toolset>msvc:<target-os>windows
  <toolset>msvc:<threadapi>win32 ;

toolset.add-requirements
  <toolset>gcc:<target-os>cygwin
  <toolset>gcc:<threadapi>pthread ;

Leaving aside auto-detection issues for the moment, I now seem to be
able to build using whatever combination I select from:

shell={bash,cmd}
toolset={msvc,hand-built-gcc}
bjam.exe={bin.cygwinx86/bjam.exe, bin.ntx86/bjam.exe}

So far so good. My problem now is that the paths to the built
artifacts are different in each case. For example, when building with
bash shell, msvc toolset, bin.cygwinx86/bjam, a certain file ends up
at:

../boost_libraries/bin.v2/libs/test/build/msvc-9.0/debug/asynch-exceptions-on/link-static/target-os-windows/threadapi-win32/threading-multi/compiler_log_formatter.obj

When building under the same shell and toolset using the
bin.ntx86/bjam the same file ends up at:

..\boost_libraries\bin.v2\libs\test\build\msvc-9.0\debug\asynch-exceptions-on\link-static\threading-multi\compiler_log_formatter.obj

Not the addition of the target-os-windows/threadapi-win32 to the first
path. I think users would prefer to be able to keep a single set of
build artifacts, both for disk space and for (re-)compilation
speed. If I understand correctly, the reason for this problem is that
the boost thread library wants to decide the default threading API and
target OS based on how the build tool was compiled with the following
rule:

local rule default_threadapi ( )
{
   local api = pthread ;
   if [ os.name ] = "NT" { api = win32 ; }
   return $(api) ;
}

I'd like to patch (at least) our local copy of the boost thread
Jamfile.v2 to fix this bug. Can anyone offer me some guidance
as to how one might establish the defaults based on, perhaps,
a combination of toolset and target-os instead?

Thanks,
Mat