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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-20 03:45:44

On Friday 18 April 2008 05:21:05 Mat Marcus wrote:
> 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?

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?

- Volodya