Re: [Boost-build] Python testing support in v2

From: David Abrahams (dave_at_[hidden])
Date: 2006-12-10 21:38:13

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
       <library-path>$(boost-libs) 
       <dll-path>$(boost-libs) 
       <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).

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.

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.

Thoughts?

Thanks in advance,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com