Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-16 17:31:02


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.

> I have talked about adding a cmake --build option
> that would do the build directly from cmake before on this list.
> Perhaps if we did that and gave it a group of settings, it would work
> more like bjam.

Depends on a lot of detail you've left out. I don't know what "gave
it a group of settings" means, for example.

> But, if someone wants to try something today with a cmake release, a
> ctest script can be used to drive the build right now.
>
> I am thinking this is more like an interface to the build system
> rather than part of it.

Not sure what that means.

> The use case you are talking about, is not that common.

Yes, as I said. However, it is very important for Boost developers
and other developers of highly portable C++.

> Most users have one compiler they work with per system. I happen to
> work with many compilers on one system. I create a binary directory
> for each of them, running ccmake or CMakeSetup to configure it for
> that compiler, and after that I run make, and cmake is re-run if it
> needs to and the software is built correctly.

IIUC you run ccmake or CMakeSetup for each member of the
compiler/project cross-product, right? If it were just once for each
compiler, it *might* be acceptable, if suboptimal. If it's once for
each compiler for each project, it's totally unacceptable.

> mkdir gcc-3.4; cd gcc-3.4; ccmake .. make cd ..;mkdir gcc-4.2; ccmake
> .. make cd ..;mkdir msvc-6.5; ccmake .. make
>
> After that initial configuration is done, if I change something,

like what? Change a source file?

> I do this: cd gcc-3.4;make cd gcc-4.2;make cd msvc-6.5; make
>
> This actually should be quite familiar to autoconf users. That is the
> basic command line interface that was copied for cmake (mkdir,
> configure; make).

Yes, and despite the fact that Boost.Build has superior abstractions,
I think most users are far more comfortable with that model.

> So, all that said, I don't think it would be hard
> to add something like what you have in bjam, but maybe python scripts
> would be sufficient. Certainly in the short term, with release
> versions of CMake, it would have to be done that way.

Hm.

-- 
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