From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-17 16:56:02
----- Original Message -----
From: "Ullrich Koethe" <u.koethe_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
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
> > 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 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk