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