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-cons
ulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|
