Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-17 16:56:02

----- Original Message -----
From: "Ullrich Koethe" <u.koethe_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, July 17, 2001 2:25 PM
Subject: Re: [boost] Re: Build Success on Boost.Python

> David Abrahams wrote:
> >
> > Thanks! Why don't you check in your proposed changes on a branch?
> >
> Done. It's on branch build-development-gcc-unix (But I think it should
> work on all platforms.)
> > > Can I automatically code the platform/OS into the build property path?
> > > (Normally, the parameters of gcc builds are identical accross
> > > so one needs another means to distinguish.)
> >
> > Are you building on one platform for a different target?
> No, we just use a central file system for all platforms. So
> is actually only one file, no matter whether I'm looking from Solaris or
> Linux. Of course, this doesn't work. So the filename should read
> $BOOST_ROOT/libs/python/build/bin/Solaris2.8/...
> and
> $BOOST_ROOT/libs/python/build/bin/Linux.whatever/...

Oh! Well, you can set ALL_LOCATE_TARGET differently for different platforms
if you like. That sets the root of the target directory tree.

> > > The Jamfile looks much more complicated than you are claiming in the
> > > motivation for ("add simple entries naming the source
> > > files"). Can this be simplified, or the functionality be absorbed into
> > > boost-base.jam or allyourbase.jam?
> >
> > Boost Python has specialized testing needs that don't apply to most
> > projects, so the Jamfile is neccessarily more complex. I guess if we
> > identify the general-purpose Python debugging stuff and separate it from
> > rest, it might be a good idea. I'm open to suggestions.
> >
> Since Beman and I are planning to resume work on boost.unit_test, it
> would be good to have a concept for unit test compilation and execution
> build int For example, one should be able to declare a
> dependency between a target and a test:
> exe myprog : myprog.cpp <lib>mylib
> : <unittest>mylibtest
> unittest mylibtest : mylibtest.cpp <lib>mylib
> The idea is that linking of myprog fails (is aborted) if the unittest
> mylibtest didn't succeed before. The test is automatically recompiled
> and re-executed if it's out-of-date relativ to myprog. Can this be
> generalized enough to be put into boost-base.jam, say?

Absolutely. I will start working on the testing side of things in the next
couple of days. David Turner has given me a result code inversion feature so
that I can add fail-expected type tests.


Boost list run by bdawes at, gregod at, cpdaniel at, john at