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

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
>        <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).

Adding

      -<define>BOOST_ALL_NO_LIB=1

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. 

- Volodya