Boost logo

Boost-Build :

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

Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk