So today I decided to take a look to a rosegarden bug I spotted the other day. It was also a good way to start testing a wrapper of mine around stg (Stacked Git) and git-svn, that allows me to easily use SVN repositories with stg. If you don’t know what stg does, but you know what quilt does, this is like the perfect quilt to work with upstream sources out of a repository, as it doesn’t break when you update the upstream sources. If you don’t know what quilt is, consider stg a nice way for a maintainer to track a patchset over upstream sources.
So, I checked out Rosegaren’s sources via stg-svn, and patched out it so that it could build with jack enabled. The patch was actually trivial, mostly needed to add a few #ifdef around. And then it was time to look at the Rosegarden ebuild.
Fist, a Gentoo service announcement: Carsten, next time you want to commit an ebuild you don’t maintain, do a favour to your fellows, and post it on bugzilla for review instead. Your Rosegarden ebuild was not compliant to Gentoo’s policy.
CMake seems to have inherited the worst of almost every build system that was developed in the last few years. From Qt’s qmake it took the absurdity of release/debug builds with different C[XX]FLAGS, from Imake it took the complicated syntax (I still wonder how can someone say that autoconf’s syntax is more complicated than CMake’s!), from scons it took the fact that no two projects seems to handle things in the same way, with the result that having an actually semi-automated handling of configuration like we can do with autotools is impossible. I don’t know from where they took the fact that they broke already a couple of time the syntax so that recent projects need a new version of cmake, and older projects need an old version of cmake. I also don’t know who the hell thought that bundling a copy of zlib, one of xmlrpc (beside, what the hell do they have to do with xml RPC?!), one of expat, one of libtar and one of curl was a good idea.
Rosegarden’s build system based on CMake had, as main problem, the fact that it totally ignore my own CXXFLAGS, as it builds releases with “
-O2 -w -fexceptions -DNDEBUG”…
-w means NO WARNINGS, so even the worst warnings would be skipped and ignored on users’ systems (if they don’t build with debug, which not only enables
-DNDEBUG, but forces
-g3 is know to break stuff, for instance glibc).
I remember being told before that to set the CXXFLAGS one just had to put
-DCMAKE_CXX_FLAGS_RELEASE="-O2 -ggdb -march=athlon64" in the cmake call, so I tried that. Too bad that when I add
-DNDEBUG like the upstream configuration does… it fails because cmake thinks that’s a directive for him not for the compiler. So the only solution for this was to… sed out the CMakeLists.txt file.
Tell me again, beside working on Windows and having coloured output, what should cmake do better than autoconf?