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

[Graeme Lufkin]

	Thanks for your comments.  I'll get working on some tutorial changes as
soon as I figure out the static/dynamic issue mentioned below.
On Fri, 2004-04-30 at 22:49, c++-sig-request at python.org wrote:
<snip>
> > 	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.
	The tutorial says that embedded apps need to use the static versions of
both libpython and libboost_python.  Is this no longer the case (or
never was the case)?  I definitely want to be able to do the
extend/embed simultaneously trick, so I'll try using shared libraries
everywhere.

> >     : <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.
	Cool.

> > 	$(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?
	Ok.
<snip>
> > 	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.
	Okay, let me explain some more.  I'm building all my extend/embed
projects outside the boost source tree.  So the extension template
builds a version of libboost_python.so in the project's bin directory,
then links the extension/embedded app against this version of the
library, correctly noticing when the Boost.Python sources have changed. 
Now suppose I have two separate projects, both external to the boost
tree.  The template entry in each Jamfile will ensure that each project
builds its own version of libboost_python, which seems a bit wasteful. 
In particular, I like to move libboost_python.so out of the
bin/boost/libs/python/build/libboost_python.so/gcc/release/etc.. tree of
directories to somewhere a little easier to get to (e.g. ~/lib) that is
in my LD_LIBRARY_PATH.  Because I know when the Boost source changes
(when I cvs update) I'm not so concerned with having each project make
sure I'm using the latest version.  I'd rather build the library once
every time I update, place it somewhere convenient, and link against
that version in my projects' Jamfiles.  Does this help explain what I'm
looking for?  Because running bjam in $(BOOST_ROOT) generates several
versions of libboost_python, those would be the ideal candidates for
this process.  Additionally, the Jamfile in $(BOOST_ROOT) has an install
target that will place the headers and built libraries right where I
want them.  And because several versions (debug/threading/etc) get
built, I should still be able to make design choices in each individual
project's Jamfile (that is, use no-debug multithreading here, debug
singlethreading over here).
	So ideally, I'd like to provide two templates (for both extensions and
embeds) to use in Jam targets: the current one that builds a separate
version of libboost_python for each project, and a new one that links
against an external version of libboost_python, the location perhaps
controlled by a variable local to the projects' Jamfile.  (And just in
case it's not clear: I don't currently know how to write such a
template, help would be appreciated)
> -- 
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com

	Something new: I tried setting ALL_LOCATE_TARGET to a valid directory
path in the Jamrules file, but it didn't do anything.  The example
Jamrules file has it commented out, has it ever been tried?  I find
extracting the library/executable from the deep tree of directories that
bjam creates to be quite annoying, so would love to take advantage of
this feature (assuming I'm correctly understanding its purpose!).
	Thanks
-- 
	- Graeme Lufkin
	gwl at u.washington.edu
This sentence does in fact not have the property it claims not to have.