From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-12-23 13:55:34
On Monday 11 December 2006 05:38, David Abrahams wrote:
> David Abrahams <dave_at_[hidden]> writes:
> > David Abrahams <dave_at_[hidden]> writes:
> >> I'm trying to build a Jamfile that declares a main target that is a
> >> python extension and then another main target that is a test of that
> >> extension. Unlike the way testing was done in BBv1, I see no obvious
> >> way to do that. The only examples I have of such tests build the
> >> generation of the extension targets into a generator, which is not
> >> only overly complex, but fails to expose the top-level target for the
> >> Python extension. Doing what I want here ought to be easy.
> > Hmm, it *looks* like that generator is able somehow to handle both
> > python extensions /and/ .cpp files as sources. Have I got that right?
> I seem to have that right, because I got it working.
> > Next problem: I want to test Boost.Python auto-linking using BBv2. I
> > built and staged the Boost.Python library, and then I declared some
> > python-extension's, and tried to build them. Somehow it started
> > building the Boost.Python binary again. It should be possible to
> > declare python extensions that don't depend on Boost.Python and there
> > should be a way to create Boost.Python extensions that use a prebuilt
> > Boost.Python.
> That was due to something that used v1 instead of v2 unintentionally.
> OK, here's my *real* problem ;-) :
> I've been writing this Getting Started guide which goes to some
> considerable effort to describe auto-linking and explains how it makes
> life better. So I figured the best way to test auto-linking would be
> to modify the Jamfile in libs/python/example to take advantage of it.
> It now looks roughly like this on my windows box (paraphrasing):
> local boost-libs = ../../../stage/lib ;
> project : requirements
> <include>../../.. ;
> python-extension getting_started1 : getting_started1.cpp ;
> # ...
> import testing ;
> testing.make-test run-pyd
> : getting_started1 test_getting_started.py
> : : test_getting_started ;
> # ...
> Actually I had to rename the file from Jamfile to Jamroot in order to
> skirt the <define>BOOST_ALL_NO_LIB imposed by Boost's root Jamfile
> (there oughta be a better way).
to requirements of your project should work.
> Anyway, it occurred to me that while this might be easy for Windows
> users, using prebuilt libraries is going to be comarative hell on
> other platforms because we don't make it easy enough for them to link
> to the prebuilt libraries we generate.
> Probably the right thing to do is create a Jamfile containing an alias
> that can stand in for each Boost library. For compilers that support
> auto-link, that might be a single target; for other compilers it would
> have to be a bunch of target alternatives that map various property
> combinations onto specific prebuilt library objects.
What is the point of such Jamfile? If somebody's using Boost.Build
to link targets, why would he want autolinking at all?
> So this leaves me wondering what advice to give my users who are just
> getting started with Boost.Python. In the near term, it seems like
> using auto-linking is going to complicate the instructions
> considerably because I'll need separate Jamfiles (or Jamfile regions)
> for compilers that do/do not support auto-linking, so I have to give
> seemingly contradictory advice: in Getting Started with Boost,
> auto-linking makes life easier. In Getting Started with Boost.Python,
> avoid auto-linking because it just complicates things.
> In the not-too-much-longer term, it seems to me that we ought to be
> able to easily build a tool that constructs a Jamfile for pre-built
> boost libraries just by sucking up the list of library files in a
> directory and parsing the mangled names. This tool should run as the
> last step of the stage and install processes.
Or we can write a generic jamfile that uses glob and regex parsing to
define a bunch of targets.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk