Re: [boost] Re: Build Success on Boost.Python

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
platforms,
> > > 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
>
$BOOST_ROOT/libs/python/build/bin/noncopyable_export/gcc/debug/runtime-link-
dynamic/shared-linkable-true/noncopyable_export.o
> 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 boost.build ("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
other
> > projects, so the Jamfile is neccessarily more complex. I guess if we
could
> > identify the general-purpose Python debugging stuff and separate it from
the
> > 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 boost.build. 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.

-Dave