From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-08 11:08:25
----- Original Message -----
From: "Raoul Gough" <raoulgough_at_[hidden]>
To: "Jam Boost" <jamboost_at_[hidden]>
Sent: Wednesday, May 08, 2002 10:41 AM
Subject: [jamboost] Re: nocygwin toolset (was: Re: Contributing new toolset
> > From: "David Abrahams" <david.abrahams_at_[hidden]>
> > ----- Original Message -----
> > From: "Raoul Gough" <raoulgough_at_[hidden]>
> > > > You don't need to rebuild jam for every compiler you want to use it
> > > > with...
> > >
> > > Yes, I see now that there are precompiled-binaries available.
> > That has nothing to do with it. You only need to recompile it once per
> > platform you're running it on. The toolset files handle the rest.
> Actually, it turns out not to be that simple on NT. The backslash path
> separator causes enormous problems when jam runs things through the
That's because the cygwin shell is actually a different platform ;-)... by
my definition of "platform".
For that, you should recompile Jam.
> The easiest way is to get a native NT-style jam that runs things via
> batch files. I managed to build jam.exe using -mno-cygwin and -DNT, but
> wasn't trivial IIRC.
> Thanks for that - it fixes the jam.exe build. Unfortunately, it turns out
> that jam_src/Jambase and allyourjambase.jam both set JAMSHELL as follows:
> JAMSHELL ?= sh -c ;
> For some reason, this ends up with execunix.c using "sh -c" as argv
> instead of splitting it into "sh" and "-c" in argv. The obvious
> consequence is that the bin.cygwinx86/jam.exe can't execute anything at
> I fixed this by removing both JAMSHELL assignments, and the (correct)
> default unix behaviour takes over. Then the gcc build actually works on
> my cygwin installation. This lack of string splitting might indicate some
> underlying problem, however I can't understand why the jam files would
> set JAMSHELL to sh -c, seeing as this is what execunix does by default
Me neither. I will make the corresponding patch.
> BTW, allyourjambase.jam also sets yacc incorrectly for CYGWIN, so it
> make sense to update this inline with jam_src/Jambase (even though it
> currently needed).
> > > Note 1. -fvtable-thunks is how I build STLport and all executables.
> > > provides compatability with COM and DirectX. Some users probably do
> > > others probably don't. I'm not sure how to make this configurable.
> > There's always the <cxxflags>-fvtable-thunks property for tweaks like
> > Else you can define your own special-purpose feature.
> I'm starting to think that almost nobody uses cygwin with boost at all,
> which case I'd be inclined to leave it hard-coded.
> I've located the problem with the regex tests, which I'll detail on the
> boost developers list. Re python, I'm having problems with includes from
> the mpl subdirectory (seems that the stuff is now in detail/...) What am
> No such file or directory
> Where select_type.hpp is actually in boost/detail
If you're compiling this, you must be looking at the pre-release
Boost.Python v2. That requires that you checkout the mpl-development branch
> I guess if needs be, I can cut-and-paste a modified link action into
> gcc-nocygwin-tools.jam (which is what seems to have happened with
Yep, it's hack city around here ;-(.
v2 cures everything, in theory. We need manpower to arrive there, however.
Volunteers welcome (hint, hint).
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