[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving away from make
From: |
Graham Percival |
Subject: |
Re: Moving away from make |
Date: |
Sat, 20 Aug 2011 05:45:00 -0700 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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