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

[David Abrahams]

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

[Please try to leave a blank line between quoted text and your reply]

> 	Thanks for your comments.  I'll get working on some tutorial changes as
> soon as I figure out the static/dynamic issue mentioned below.

Thanks; it's much appreciated.

> 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)?  

Never was.

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

Why do you think it will do that?

Normally, targets are built into a bin/... tree below the location of
their Jamfiles.  If you set ALL_LOCATE_TARGET=/some/path then all
targets will be built into a single build tree rooted at
/some/path/bin.  Either way, there's a single Jamfile where
libboost_python is defined so you won't get duplication.

> 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?  

Yep.

> Because running bjam in $(BOOST_ROOT) generates several
> versions of libboost_python, those would be the ideal candidates for
> this process.  

So you can move those, and replace <lib>boost_python with the
appropriate <find-library>... and <library-path>... options.

> 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, 

Well, it doesn't, but...

> 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)

I guess it mostly comes down to using <find-library>library_name and
<library-path>path/to/search/for/libs.

>> -- 
>> 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 certainly use that feature all the time, although I set it in my
environment.  There were a few weeks when it was broken, but AFAIK
Rene fixed it again before 1.31.0.

> 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!).

Well, maybe you're not.  It doesn't make the tree any less deep; it
just unwinds the tree from the build tree (the one containing the
Jamfiles).

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