[CMake] Is CMake powerful enough?

[Brandon Van Every]

On 6/8/07, gga <ggarra at advancedsl.com.ar> wrote:
mbers> Oliver Kullmann wrote:
> >
> > A lesser problem (likely) seems to be that there is no really fine-grained
> > control over where all those auxiliary files go? It seems the basic assumption
> > is that of having a build-directory (used only once), where all sort of stuff
> > can be dumped to, and then with the final "make install" the "relevant"
> > files are moved elsewhere? This does not neatly fit with our permanent use
> > of the build-system, but likely one could live with it (by automatically
> > always running "make install").
>
> This is indeed somewhat of a problem with cmake.
> Out-of-source builds are not 'built-in' so you need to do something like:
>
> > mkdir buildir && cd buildir && cmake ..

Only on Unix.  On Windows, we fire up CMakeSetup and get a nice GUI
for this.  On Unix there is CCMake, which provides a character based
GUI, but you're right that you do have to create the out-of-source
directory yourself.  I have wondered why the setup of CCMake differs
in this trivial matter from CMakeSetup.  I would think having the
tools work the same way on all platforms would make documentation and
user training simpler.  In fact, I should probably check my build
instructions to see if I've missed this subtle point.

> > && make

That's up to what build system you generated.  If Makefiles then of
course you type "make".  If Visual Studio .sln files then of course
you don't, you open the .sln and click on a target inside of it.

> CMake provides some variables that can be set to control where output
> goes (see Wiki - useful variables).  With them you can control where .a,
> .so, executables and the like get placed.
> The only thing you don't really have as much control over is where .o
> files go, as CMAKE_BINARY_DIR is more or less broken,

Perhaps you meant "broken for choosing where .o files go."  It works
quite well for everything else.

>but in principle you should not have to worry about that.

I've worried about it for faking convenience libraries.  I re-use the
.o files that were built in a previous library.  My code works, but it
relies on under-the-hood knowledge of where CMake puts the .o files.
No guarantees that it'll keep working, so thanks for reminding me to
make a feature request in the bug tracker.

Kitware is quick to respond to feature requests.  They're a good
business partner.  As far as I'm concerned, that's the strongest
reason to use CMake.  They gave me a 1st cut of my Chicken Scheme
build system once upon a time.  Of course I've altered it beyond
recognition, but the point is, they provided an important piece of
support when I was just getting started.


Cheers,
Brandon Van Every