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

From: Raoul Gough (RaoulGough_at_[hidden])
Date: 2002-05-10 04:32:11

>    Date: Wed, 8 May 2002 11:08:25 -0500
>    From: "David Abrahams" <david.abrahams_at_[hidden]>
> Subject: Re: Re: nocygwin toolset (was: Re: Contributing new toolset
support)
>
>
> ----- Original Message -----
> From: "Raoul Gough" <raoulgough_at_[hidden]>
> To: "Jam Boost" <jamboost_at_[hidden]>
> Sent: Wednesday, May 08, 2002 10:41 AM
>
> > 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'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? Note that it
currently requires a change to gcc-stlport-tools.jam, replacing = with ?=
for the two assignments to GCC_STLPORT_LIB_ID.

>
> > 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.
>
> > > > 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'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. 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. 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.

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

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

Thanks, that fixed that problem. Does this suggest that the mainline on
libs/python is out of synch with the mainline on boost/detail?

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

Regards,
Raoul Gough.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com