Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-17 10:33:15

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

> David Abrahams wrote:
>
>>> 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.
>
> I mean create some sort of config file in the cmake language that can 
> specify things similar to the ones in the user-config.jam file, and
> make it more declarative than the ctest -S script currently is.
>
>> 
>>> 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.
>
> I am not sure either...  (:
>
> I guess I was trying to say that cmake can build a single 
> compiler/settings directory well now. The ability to build more than one 
> configuration in one run of cmake would be adding extra stuff to CMake 
> that it really does not belong there, and that an interface on top of 
> cmake, a python script, cmake script, or something else is what is 
> needed.  Basically, you want a higher level interface to cmake that can 
> build for multiple compilers all with one command.
>
>
>> 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.
>> 
>
> Depends on what you mean by a project?   

I mean "independently developed source code base."  The sort of thing
that is usually stored in an IDE's project file.

> The cmake stuff that Doug has 
> done has cmake files for all the projects in boost.  You would run cmake 
> at the top of the boost tree, and then be able to build all the projects 
> at once, or each project by itself.  However, you could run cmake for 
> each project if you wanted to only build a small part of boost, and in 
> that case cmake would be run once for each project.  So, I think the 
> answer is that it would be one ccmake for each compiler set for all of 
> boost.

Yeah, but I wasn't just talking about Boost.  A company developing
three applications will have a separate project for each one.  If I
download the source for an open source library (say libjpeg) and build
it, that would be one project.  If I were to write an image-processing
app that uses libjpeg, that's another project.  I should go back to
talking specifically about Boost, though, because it isn't my goal to
make CMake a good tool for general devlopment of portable code.

Also, don't forget it's not just compilers; it's all build resources.
So for example you might test code with five compilers and three
versions of python.  Any given combination of those build resources
(or all) could be important.

>>> 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?
>
> Change a source file or a cmake input file.  If an input to cmake 
> changes, then cmake will automatically re-run itself, if a source file 
> changes then it will get rebuilt, but you don't have to specify the 
> configuration options more than once per build tree, only the first time.

...

>>> I do this: cd gcc-3.4;make cd gcc-4.2;make cd msvc-6.5; make

Yeah, I understand that.  Once you have the configured directories set
up, building any number of configurations is pretty easy.

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