Re: [Boost-build] Future development

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