[C++-sig] Re: bjam rules for building embedded applications

[David Abrahams]

Graeme Lufkin <gwl at u.washington.edu> writes:

> 	Looking at the new(ish) example/Jamfile, I've (I think) figured out the
> recommended way to build Boost.Python extensions.  Extrapolating the
> idea, I've created a similar Jam template for embedding applications. 
> Please critique it, to verify that I'm correctly understanding how bjam
> works in this instance.  If members of the list agree with my
> understanding, I can update and submit diffs of the tutorial, which
> still uses old-style Jamfiles for both extensions and embedding.
> 	To build an extension, you use the extension rule and include the
> extension template (<template>@boost/libs/python/build/extension, where
> @boost is defined in the Jamrules file to point at the boost source
> tree) in the list of sources.  This will build two shared libraries in
> the bin directory, libboost_python.so and your extension.  The template
> checks for updates to the Boost.Python source and automatically
> rebuilds.
> 	To build an embedded application, we will use the exe rule and an
> embedding template defined below.  This template should get added to
> libs/python/build/Jamfile in the Boost sources.
>
>   template embedded
>     : <lib>boost_python #embedded needs static library, not dynamic

Actually, using the dynamic library is fine, and probably neccessary
if you want to do the extending/embedding thing where some extension
modules you want to use are separately linked shared objects.

>     : <sysinclude>../../.. #boost headers

      this ties you to a particular relative location w.r.t Boost.

Much better to write:

        <sysinclude>@boost

which puts the root path of the Boost project right there... oh, I see
later on that you seem to be putting this in python.jam, so a relative
path isn't so bad.  I still think project-relative is better.

> 	$(BOOST_PYTHON_V2_PROPERTIES) #Python include/linking dirs

That's wrong; it includes, among other things,
<define>BOOST_PYTHON_DYNAMIC_LIB, which conflicts with the fact that
you happen to be using the static library.  Looking at
libs/python/test/Jamfile I think $(PYTHON_PROPERTIES) is what you want
here.  Why don't you just use that as your example?

> 	<find-library>$(PYTHON_EMBEDDED_LIBRARY) #libpython

OK.

> 	<find-library>pthread #needed for my system

OK, I guess.  Ought to be handled by python.jam I think.

>     ;
>
> This template is used exactly as the extension template, for example in
> the Jamfile:
> exe embedded_test
>   : embedded_test.cpp
>   <template>@boost/libs/python/build/embedded
>   ;
> This will build libboost_python.a (a static library) and your
> executable, again checking for updates in the Boost.Python source tree.
>
> 	Okay, some notes: I needed to add the <find-library>pthread on my
> system (RH9, gcc 3.2.2, Python 2.2.2).  If this isn't only observed on
> my system, it should probably be added to the definition of
> $(PYTHON_EMBEDDED_LIBRARY) in tools/build/v1/python.jam

Right.

> 	The tutorial (both the extending and embedding examples) uses Jamfiles
> with lots of other stuff that (at best) doesn't appear to be necessary
> and (at medium) is confusing to the reader and (at worst) doesn't work
> anymore.  I volunteer to update the tutorial on this point.  

Graciously accepted!

> Are diffs to the CVS version submitted to this list the appropriate
> way to do this?

Yep.

> 	Some questions: If I've got several separate programs (either
> extending, or embedding) using this technique, then each one has their
> own version of libboost_python.[a|so] which seems rather wasteful.  Is
> there a recommended way to use a libboost_python.[a|so] in a fixed
> location?  That is, please provide a Jamfile entry to do this.

I don't understand the question.  You can link to the shared
boost_python by substituting <dll>boost_python for <lib>boost_python.

> 	When building all of boost (that is, running bjam in $(BOOST_ROOT) ) it
> makes several versions (compiler/threading/debug) of the libraries (not
> just Boost.Python) and (optionally) installs them to a given location. 
> Could the extension and embedded templates be reworked to link against
> these versions of libboost_python

I think so, but then they won't update the Boost.Python library
automatically when its sources change.

> so that (as requested above) there is only one source of the library
> to link against?  

I'm not sure what "there is only one source..." means

> How might this be done?  Thanks very much for your
> patience reading this long message.  -- - Graeme Lufkin
> gwl at u.washington.edu "This sentence contains exactly threee erors."

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com