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