Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-15 16:14:06

on Fri Oct 12 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:

> Rene Rivera wrote:
>> Bill Hoffman wrote:
>>   
>>> An initial cache file could be the same as the
>>> user-config.jam file.   I have not used jam, but I assume you have one
>>> of these per compiler.
>>>     
>>
>> For your info... An example user-config.jam 
>> <http://beta.boost.org/development/tests/trunk/RSI%20Droid.html>. It's 
>> the one I use on the Linux test machine.
>>
>>
>>   
> OK, so in the CMake world, that would be closer to ctest -S build 
> script, that we
> use to populate our dashboards.   Here is an example:
>
> http://www.cmake.org/Testing/Sites/grayson.kitware/Win32-nmake80/20071013-0100-Nightly/Notes.html

I don't think so.  Rene's point is that the user-config.jam file
specifies the locations of all his build resources: multiple versions
of g++, one (in this case) version of python, and all versions of
doxygen the system can find.

  using gcc : : /usr/bin/g++ ;
  using gcc : 4.1.2~linux~x86 : /usr/bin/g++ ;
  using gcc : 4.2.0~linux~x86 : /usr/local/gcc-4.2.0/bin/g++ ;
  using gcc : 4.2.1~linux~x86 : /usr/local/gcc-4.2.1/bin/g++ ;
  using python : 2.5 : /usr ;
  using doxygen ;

also, the following incantations are an old style of autoconfiguration
request to find the default installations of these tools:

  import xsltproc-config ;
  import boostbook-config ;
  import quickbook-config ;

The modern style would replace "import xxx-config" with "using xxx".
In general, Boost.Build supports a model where you can tell it about
any number of installed tools, and request builds using arbitrary
combinations.  CMake doesn't support that model as far as I can tell.
It's an important model for many Boost developers (like me), who are
trying to create and test highly portable code.  In my opinion, it's
unimportant to most Boost users, who want to use one set of installed
tools and usually prefer their own build systems anyway.

It seems like most of this capability could be accomplished relatively
easily with a thin layer on top of CMake, but it will never be as
smooth and flexible as it is in Boost.Build unless it is integrated
into the system.  My question is, do we really need to be able to
specify arbitrary combinations of tools on the bjam/cmake command
line, or is it enough to configure the combinations we're interested
in, each using its own build tree?

> When you run ctest -S on that script it will update cvs, run cmake,
> build the software, run the tests, and send the results to the
> dashboard server.  You could use it as just a build script and leave
> out the update and submission stuff.  It would be a closer fit to
> the user-config.jam.  It has the machine specific stuff like paths
> to compilers and versions of things like python in it.  You would
> have a separate one for each compiler

I think that makes the analogy to user-config.jam a poor one.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com