Re: [boost] Re: nocygwin toolset (was: Re: Contributing new toolsetsupport)

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-10 05:23:22

Moving this to jamboost_at_yahoogroups.com...

----- Original Message -----
From: "Raoul Gough" <RaoulGough_at_[hidden]>

> > Date: Wed, 8 May 2002 11:08:25 -0500
> > From: "David Abrahams" <david.abrahams_at_[hidden]>
> >
> > ----- Original Message -----
> > From: "Raoul Gough" <raoulgough_at_[hidden]>
> >
> > > 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.
>
> I guess I'll have to put together the changes necessary to build an
> NT-native jam using cygwin gcc.

I'm sure the jam executable itself is fine, modulo small changes that may
need to be made to the Jambase... hmm, no, there appears to be something
wrong with the way commands are invoked. A Jam built under Cygwin can
bootstrap itself, but when used in Boost.Build there is some kind of
problem. If you use

jam <options> -ofile <targets>

It will write a file which you can invoke iwith the shell, FWIW.

> I'll get to this later, but for the moment,
> I've finally got a working gcc-nocygwin-tools.jam. I'm not sure where
best
> to post it, so for a short time it will be available via
>
> http://myweb.tiscali.co.uk/raoulgough/gcc-nocygwin-tools.jam
>
> Dave, maybe you could copy this to a more permanent home?

OK, I'll check it into the release candidate branch. Great, another
platform I can test with ;-)

> Note that it
> currently requires a change to gcc-stlport-tools.jam, replacing = with ?=
> for the two assignments to GCC_STLPORT_LIB_ID.

I think that change is harmless enough. Anyone with objections, please
speak up!
We are currently writing toolset configuration descriptions, as you can see
from the CVS. Could you please submit one for your new toolset?

> > > > 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'm not sure what you meant by the "<cxxflags>-fvtable-thunks property".
I
> couldn't find any reference to this flag at all in the mainline CVS.

<cxxflags> is a free-feature which adds its value to the C++ command-line
without modification.

> In any
> case, I never figured out how to select this kind of feature for the
build.
> I managed to select debug or release via -sBUILD=... but couldn't see any
> way to select (for example) dynamic linking only.

Dynamic linking (except to the runtime) is a property of the target you're
building; you can't select it that way. Sometimes even the method of
linking to the runtime is constrained by a target's requirements. If you
want <runtime-link>dynamic only, you can just put it in your BUILD
variable:

-sBUILD="release <runtime-link>dynamic"

> At least not across the
> whole build - I could do it via a fully qualified target name like
>
<libs!thread!test\test_thread.exe\gcc-nocygwin\release\runtime-link-static>
t
> est_thread.exe but this is tedious, to say the least.

Yes, to say the least.

> Instead I've made the vtable configurable via an environment variable,
but
> this is not ideal if you want to build both variants.

Nope.

> > 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
>
> Thanks, that fixed that problem. Does this suggest that the mainline on
> libs/python is out of synch with the mainline on boost/detail?

Nope. Boost.Python v2 and v1 coexist in the main trunk of the CVS for the
time being.

> There is one remaining problem with python, but it only occurs in the
debug
> build. The module is question is libs\python\example\simple_vector.cpp.
> Could it be something to do with vector iterator not being a pointer?
It's
> being compiled with STLport's debug STL via -D_STLP_DEBUG and produces:
>
> d:/boost/CVS/boost/boost/python/caller.hpp: In function `static struct
> PyObject * boost::python::caller<unsigned
> int>::call<_STL::__vector<double,_STL::allocator<double> > >(size_t
> (_STL::__vector<double,_STL::allocator<double> >::*)() const, PyObject *,
> PyObject *)':
> d:/boost/CVS/boost/boost/python/detail/functions.hpp:73: instantiated
from
> `boost::python::detail::wrapped_function_pointer<unsigned int,unsigned
int
> (_STL::__vector<double,_STL:
> :allocator<double> >::*)() const>::do_call(PyObject *, PyObject *) const'
> f:/stlport/STLport-4.5.3/stlport/stl/debug/_iterator.h:153:
instantiated
> from hered:/boost/CVS/boost/boost/python/caller.hpp:232: no matching
> function for call to `from_python (PyObject *&,
> boost::python::type<_STL::__vector<double,_STL::allocator<double> > &>)'

I don't think so. Not sure what the problem is there.

> > 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).
>
> I'm willing to have go - have you got any specific jobs that need doing?
I
> mean ones you can explain to me quicker than doing it yourself :-)

Right now we are just trying to clean up the v1 documentation to cut down
on the support requests and bafflement for 1.28.0. That seems like a job
you could easily help with. We can get you up to speed on v2 once 1.28.0
has been released. I'd be happy to give you CVS access if you'll send me
your SourceForge UserID.

-Dave