Re: Moving away from make

[Graham Percival]

On Sat, Aug 20, 2011 at 11:06:29AM +0200, Jan Nieuwenhuizen wrote:
> Han-Wen Nienhuys writes:
> 
> > Given that Cmake has a large following (examples include KDE and
> > LLVM), I'd be comfortable with switching to that.
> 
> Interesting; have you ever used Cmake?

I migrated Marsyas (a moderately-sized project; 200,000 lines of
code) from a combination of autotools and qmake (i.e. two separate
build systems, maintained in tandem!) to cmake.

> Last time I looked (migrated a cmake project to autotools), Cmake did
> only have proprietary documentation

Yes.  Most of my cmake knowledge from reading slides of conference
presentations and bug reports on their mailing list (or on blogs).

> introduced a rather crappy home brew language,

Change that to "extremely crappy home-brew language".  Their
crappy home-brew language is ridiculously far away from the
readability of modern scripting languages like python and lua.
That said, it still avoids the confusing $< $@ syntax from make.

> cached make information in generated makefiles that do not use
> variables for $(CC) or $(CFLAGS),

I know it's extremely easy for users to change CC/CFLAGS/CXXFLAGS
variables during the cmake configure stage.  IMO, the generated
makefiles aren't particularly intended to be human-readable.

> has a IMHO nasty way of overriding such variables on the
> cmake command line.

Never use the cmake command line; always use ccmake (or even the
graphical one, although I've never done that myself).

> Also, it did not have an easy way to create
> help from the command line

There's good help strings in ccmake; I'm not bothered by this one.

> or a facility to have virtual targets or a nice way to say:
> `make -C lily out/parser.o' because all file names were
> absolute, fully expanded names.

Hmm, I can't comment either way on this one.  I'd be surprised if
there was no way to do this, but OTOH I've been surprised about
some brain-dead cmake stuff in the past.

Most recently: in cmake 2.6, you can specify a working directory
for a compile target, but you can't specify a working directory
for a unit test.  Recommended solution: write a python wrapper
that changes to the relevant directory and runs your command, then
exports the exit code.


Overall, cmake is not an unambiguous win... but if I were starting
a new moderate-sized project, I'd probably use cmake rather than
any of the other build systems.

Cheers,
- Graham