boost-build path discrepancies

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?
>
>thanks.
>michael