
On 13 February 2012 20:20, Robert Ramey
2) the only way I've found to use the current tools is to create directories in my local boost release tree with my "experimental" library and run bjam.
Boost Build is meant to work without the boost tree. If you've used the bootstrap install it should install all the necessary boost build files along with the executable. I just tried creating a simple "hello world" example. In an empty directory I created a 'hello.cpp' file, with this in Jamroot.jam: exe hello : hello.cpp ; And that worked fine (well, I had to comment out my 'using bookbook' line, for similar reasons that you did with 'using xsltproc'). Just remember that there needs to be a Jamroot.jam in the root directory, so that boost build can know where the root of the tree is. Depending on boost is a little more complicated. Take a look at: http://svn.boost.org/svn/boost/sandbox/example/ If you've set the BOOST_ROOT environment variables to the location of your boost tree, it should be possible to build it separately from boost. In the root is a Jamroot.jam file which will use boost located at $BOOST_ROOT. If the BOOST_BUILD_PATH logic was removed, it could be simpler: path-constant top : . ; import modules ; import path ; local boost-root = [ modules.peek : BOOST_ROOT ] ; if ! $(boost-root) { ECHO "Error: BOOST_ROOT not set" ; exit ; } path-constant BOOST_ROOT : $(boost-root) ;
iv) For an example to iii) above, I had tweaked userconfig.v2 to include the name of my xsltproc program which was found through the path. Later I elimnated the directory of the xsltproc from my path. Later I found I couldn't build my library or run any tests. Turned out that bjam stopped when it failed to find the xsltproc program - even though it wasn't being used. I'm not critisizing bjam. I think it's impossible to make a program as ambituous as this totally perfect. But I question the need for such an elaborate tool for doing what seems to me should be something simple.
Maybe toolsets like xsltproc and boostbook should check for files lazily (i.e. only when they're actually used). Possibly with a command line option to get boost build to check all of the toolsets mentioned in configuration jamfiles. Strictly speaking, default 'using xsltproc' or 'using boostbook' directives wouldn't be required if all documentation Jamfiles contained the appropriate 'using' directives. But most people don't realise this. It'd be nice if it was an error if they're missing, or just a warning at least, but I don't think that's easy to do.