Graeme Lufkin <gwl@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@u.washington.edu "This sentence contains exactly threee erors."

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