Re: [Boost-build] Future development

From: Bill Hoffman (bill.hoffman_at_[hidden])
Date: 2007-10-15 17:41:34

David Abrahams wrote:
>
>> /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?
I saw that the config file had multiple compilers in one file.  I think 
this could be done in a single
ctest -S file.   Having to create a script or thin layer on top of cmake 
would most likely be not
that cross platform.  (Might depend on python or some shell being 
installed.)  In this respect,
that is why I thought it might be close to the ctest -S scripts.   When 
we started doing dashboards
we had shell scripts and .bat files to drive the process.  However, this 
was hard to
maintain.  So, we added support to ctest to process cmake scripts.   The 
feature could be used
to do what you want.  

I am thinking something like this:

# set a root path for builds
set(CTEST_BINARY_DIRECTORY "/home/me/my_builds")
# initialize the cache with the compiler and tools you want for the system
file(WRITE "${CTEST_BINARY_DIRECTORY}/BinaryOne/CMakeCache.txt" "
CMAKE_CXX_COMPILE=/usr/bin/g++
")
# run cmake
ctest_configure (BUILD "${CTEST_BINARY_DIRECTORY}/BinaryOne/")
# build the project
ctest_build (BUILD "${CTEST_BINARY_DIRECTORY}/BinaryOne/")

# create a second build tree for the next compiler
file(WRITE "${CTEST_BINARY_DIRECTORY}/BinaryOne/CMakeCache.txt" "
CMAKE_CXX_COMPILER=/usr/local/gcc-4.2.0/bin/g++
")
ctest_configure (BUILD "${CTEST_BINARY_DIRECTORY}/BinaryOne2/")
ctest_build (BUILD "${CTEST_BINARY_DIRECTORY}/BinaryOne2/")

Then you could build both with ctest -S mybuild.cmake.
I am not sure this works right now, because there might be some
dashboard specific stuff that might be required, but I don't think
it would be hard to make this work.  It all depends on if you folks
think it is useful.

-Bill