[C++-sig] Re: bjam rules for building embedded applications
dave at boost-consulting.com
Fri Apr 30 20:35:02 CEST 2004
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
> 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:
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
> <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
> 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
> 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.
> Are diffs to the CVS version submitted to this list the appropriate
> way to do this?
> 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."
More information about the Cplusplus-sig