Re: [jamboost] Re: nocygwin toolset (was: Re: Contributing new toolset support)

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
support)

> > 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
cygwin
> shell.

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
it
> 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[0]
> instead of splitting it into "sh" and "-c" in argv[1]. The obvious
> consequence is that the bin.cygwinx86/jam.exe can't execute anything at
all.
> 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
> anyway.

Me neither. I will make the corresponding patch.

> BTW, allyourjambase.jam also sets yacc incorrectly for CYGWIN, so it
might
> make sense to update this inline with jam_src/Jambase (even though it
isn't
> currently needed).

OK.

> > > Note 1. -fvtable-thunks is how I build STLport and all executables.
This
> > > provides compatability with COM and DirectX. Some users probably do
> this,
> > > others probably don't. I'm not sure how to make this configurable.
> >
> > There's always the <cxxflags>-fvtable-thunks property for tweaks like
> this.
> > Else you can define your own special-purpose feature.
>
> I'm starting to think that almost nobody uses cygwin with boost at all,
in

I do.

> 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
I
> missing?
>
> e.g.
>
> f:/boost/CVS/boost/boost/python/detail/indirect_traits.hpp:11:
> boost/mpl/select_type.hpp:
> 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
of $(BOOST_ROOT)/boost/mpl

> 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
> mingw-tools.jam).

Yep, it's hack city around here ;-(.
v2 cures everything, in theory. We need manpower to arrive there, however.
Volunteers welcome (hint, hint).

-Dave