Re: Future development

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
"$/BinaryOne/CMakeCache.txt&quo
t; "
CMAKE_CXX_COMPILE=/usr/bin/g++
")
# run cmake
ctest_configure (BUILD
"$/BinaryOne/")
# build the project
ctest_build (BUILD
"$/BinaryOne/")

# create a second build tree for the next compiler
file(WRITE
"$/BinaryOne/CMakeCache.txt&quo
t; "
CMAKE_CXX_COMPILER=/usr/local/gcc-4.2.0/bin/g++
")
ctest_configure (BUILD
"$/BinaryOne2/")
ctest_build (BUILD
"$/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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Re: Future development

Thread: Re: Future development