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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
