Boost logo

Boost-Build :

From: Michael Hunley (mhunley_at_[hidden])
Date: 2003-03-13 17:00:50

>As per my recent post "Installing boost libs for dependant apps," I
>recently used the boost-build system for my own apps make setup. I found
>it to be very powerful and useful (more than I could use to begin
>with). I used the version 1 build system becuase it looked like it would
>be easier to get up and running, but plan to migrate to v2 soon since it
>is more powerful and I much prefer the dependency handling of adding
>sub-projects by name, not path to a Jamfile. But I need to learn it
>first. I did this on RedHat 8.0 using gcc 3.2.2 with a cut of the Boost
>CVS from 2/6/2003 on the Boost-Build v1.30.0. I copied most of the main
>files (features.jam, boost-build.jam, etc) from the main boost build setup
>in BOOST_ROOT and BOOST_ROOT/tools/build.
>I ran into two issues with pathing and another with the LinkLibraries
>rule. I tried a couple of approaches to including externally built
>libraries to my build hierarchy (several sub-project libs and one
>app). When I tried LinkLibraries it didn't complain, but the library
>never got added to my link action in the NEEDLIBS variable. I tried
>tracing it down and added Echo actions to the LinkLibraries to see what it
>was adding, which was nothing, but I could have mis-understood the
>NEEDLIBS on $(<) expression. Regardless, they did not appear in the list
>of libs passed to the linker. I then tried the <libraryfile> feature in
>my requirements section. That worked fine. So, is LinkLibraries
>deprecated (the docs did not mention it that I could find)? I had it
>first in my list, before my exe target, but in the same file. Was it
>supposed to go after? I liked LinkLibraries better than the <libraryfile>
>since it would do the name mangling for me (prefix="lib", suffix=".so"
>under gcc).
>The other problem I ran into revolved around use of relative paths and I
>believe my results are counter to what the documentation claims. First,
>when I added dependant libraries as source entries in my exe target the
>docs claim I can make those paths absolute. My setup is a little out of
>the norm in that my app is at the leaf node of the directory tree, so the
>relative path to the main lib it needed was $(DOTDOT). However, I have
>several libs common to other apps, but in the same boost build hierarchy,
>so those are relative to $(BOOST_ROOT). When I tried having a source line:
> <lib>$(BOOST_ROOT)/Common/CommonLib
>from within my Jamfile located at $(BOOST_ROOT)/ServerLib/Server
>The output when I tried bjam was:
> (|ServerLib|Server|home|michael|Proj|Common) not found
>(I am only sure of the folder part of that, the exact error syntax may be
>slightly off). I had to specify the paths as:
> $(DOTDOT)/$(DOTDOT)/Common/CommonLib
>In the second case, it was relative pathing that wouldn't work. I
>specified most of the common features and settings using template targets
>that I then imported into each Jamfile (Very nice feature). The one of
>concern was located in the $(BOOST_ROOT)/ServerLib folder. In the
>$(BOOST_ROOT)/ServerLib/Server/Jamfile I added a requirement:
> <include>$(DOTDOT)
>To get back to ServerLib which it depends on. I swear that worked the
>first time I got it built, but last night when I did a rebuild all (bjam
>-a) it failed and claimed it could not find include files. I ended up
>having to change it to absolute pathing to work.
>Are the docs wrong on the two pathing issues? Is there something I could
>be setting up wrong to get the behavior I saw?


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at