[Boost-build] 2nd try: Python testing support in v2

From: David Abrahams (dave_at_[hidden])
Date: 2006-12-23 13:12:08

I am trying to get Boost.Python ready for release with BBv2 and I
really need some help here.

David Abrahams <dave_at_[hidden]> writes:

> 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