Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-17 10:39:05

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

> David Abrahams wrote:
>> on Mon Oct 15 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
>> 
>>>>> 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.
>>>>>     
>>>> Not in that form, IMO.
>>>>   
>>> OK, I guess I was looking for a solution that we already had.  We have
>>> the ctest stuff, and it was created for a similar reason.  I tend to
>>> be overly pragmatic and look for solutions that can be done today with
>>> a release of cmake.  
>> 
>> Always a good thing to try first.  Just doesn't work in this case.
>> 
>
> So, maybe this could work with a new "Doug Layer"... I suppose you could 
> use macros to make it look better and be less redundant.  Something
> along the lines of this:
>
> mybuilds.cmake
>
> include(boostbuild.cmake)
> set(cxx_compiler /usr/bin/g++)
> set(python python2.5)
> set(use_doxygen 1)
> set(source_dir /path/to/boost)
> set(binary_dir /path/to/boost/build-g++)
> build_configuration()
> set(cxx_compiler /usr/local/gcc-4.2.0/bin/g++)
> set(binary_dir /path/to/boost/build-g++-4.2.0)
> build_configuration()

Still way too dense and redundant for my tastes.  Also, it's got one
fundamental problem for a generalized build tool for portable: there's
no way for the user to describe his available build resources
separately from the specifics of this particular project.  The
information that there's a g++ in /usr/bin and an g++-4.2.0 in
/usr/local/gcc-4.2.0/bin/ is useful in all my projects, while the
choices of specific binary directories are specific to my work on a
particular installation of Boost.

That said, though not great, it's probably good enough for Boost's
needs.

> ctest -S mybuilds.cmake
>
>
> I am thinking you could make the macro smart enough to only explicitly 
> run cmake the first time.  After that it would run the make directly, 
> and avoid the extra configure step when it is not needed.  Anyway, I am 
> not sure how important this feature is, but I think something like this 
> could be done with the current cmake release without much trouble.

If so, I'd like to see it.

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