boost-build path discrepancies

From: Michael Hunley (mhunley_at_[hidden])
Date: 2003-03-07 16:43:41

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?

thanks.
michael