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 -O0 and -g3 — -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?
I generally prefer working with the pmake system these days. It’s just oh so simple to write makefiles for it 🙂
what about -DCMAKE_CXX_FLAGS:STRING=”-O2 -ggdb -march=athlon64″ -DCMAKE_C_FLAGS:STRING=”-O2 -ggdb -march=athlon64″ ?
if only bitbake has a saner syntax…… or people starts using msys in order to build their fun win32 ports …
I think the main problem for the autotools are all those bad scripts out there which are copied all the time. A correctly done setup isn’t too hard to maintain and efficient. But it takes time to find a good example to learn from…
… and the scripts are copied because nobody understands them.Ok, now on to the points from the original post:> From Qt’s qmake it took the absurdity of release/debug builds with different C[XX]FLAGS,I’m not sure I understand. You think it’s absurd to use different flags for release and debug builds ? Don’t see why. I think it’s absurd to find that absurd ;-)> from Imake it took the complicated syntaxCMake syntax:command(arg1 arg2 arg3 … ${dereferencing_a_variable})That’s basically all there is to cmake syntax.> with the result that having an actually semi-automated handling of configuration like we can do with autotools is impossibleI don’t know what you mean with this. Can you please elaborate ?> I also don’t know who the hell thought that bundling a copy of zlibIf you really want, you can use the shared libs installed on the system. But there are reasons why these libs are included in CMake. Basically this is to have no external dependencies. This makes it much easier to build on various (exotic) platforms, which may not have all that available. It also means that CMake doesn’t link to any (other than libc and libstdc++) shared libs. So it doesn’t matter which versions of the libs are installed. Or in which locations. This means you can install the binary distribution of CMake on basically any Linux distribution in any directory and it will just work.> the fact that it totally ignore my own CXXFLAGSCMake uses the CFLAGS and CXXFLAGS which were set when cmake was run the first time on a project.> -DNDEBUG like the upstream configuration does… it fails because cmake thinks that’s a directiveYes, that’s what the documentation says: -D <var>:<type>=<value> = Create a cmake cache entry.> what should cmake do better than autoconf?autoconf alone isn’t *that* bad, the problem is that generally it is used together with automake and libtool, and you need to know makefile, shell and m4 syntax. Also it requires a shell in order to work. It supports only makefiles, CMake can create projects for KDevelop, CodeBlocks, Eclipse, XCode, MSVC. CMake has built-in support for packaging. CMake has built-in support for unit testing and continuous integration. CMake now natively supports cross compiling to any platform, also targets like 8bit uCs without any OS. CMake actually ofers a GUI to set up build options. CMake has advanced RPATH handling. CMake has a very responsive mailing list with helpful developers (which would have helped if you had posted there).You want me to continue ?Alex
I have a dim memory of working with Imake from the early 90’s. I can’t honestly remember what Imake syntax was like. I don’t remember it being particularly weird.
I agree that function calling conventions are simple. They have never tripped me up. Quoting and escape conventions are another matter entirely. Definitely pitfalls there. I am too lazy to do a better job of documenting them at present. Today I explained the pitfalls of escaping The Almighty Dollar. I still don’t feel up to explaining the benefits vs. unsafeties of semicolons, which are used as list separators. Lists are extremely convenient when used properly, but without proper knowledge, it’s easy to get list and string representations confused.
Darned URLs. “The pitfalls of escaping the Almighty Dollar”:http://www.cmake.org/Wiki/C…
Don’t you think that the CMAKE is more build system generator instead of build system?And that is probably the reason why it suffer from all known build system illnesses.I c cmake as good friend when I want to generate multi-platform builds. In case my project is platform specific and isolated then I can use the best build system available on selected platform.Is it there another simple multi-platform build system or build system generator available? It would b really nice to know about such think.
Sure, syntax of CMake isn’t really complicated, it’s just too simple or say “poor”, that using it is a complicated work. Moreover, it seems more imperative than declarative, and the same thing (I, particularly, once worked with 3rd-party library that use CMake) is more shortly and even clearly can be expressed in plain Makefile, than in all those CMakeLists.txt. The only thing that need to Makefiles’ be portable – it’s port the make to another platform (GCC make already ported on various platforms, isn’t?)Someone here wrote, that CMake integrates many things, like own unit testing, packaging. Isn’t just a build system, but rather swiss-knife? There are already a plenty of Unit Testing frameworks, packaging tools etc, that many developers already chose, learned and used to work with, why any build system should introduce it own “bicycles”. I thing, build system must do what they name suggest – build things, invoke external tools and make they work together, and more important – it must make that task as easy as possible for developer; developer don’t need to learn any new command-like syntax and new quirks of another build system, the build system is a supplementary software and ideally developer must even not notice it. To me, I prefer qmake (it work on almost all major PC platforms). After all, what you need to build any executable (either dynamic lib, static lib or plain executable) – is 4 things (for C/C++ at least): 1) list of source files; 2) list of headers; 3) list of linked libraries and list of corresponding include dirs; 4) the ability to play with sets of flags and configuration macroses for compiler and linker. The QMake just want you to list this 3 things (at minimum) and nothing else.
Found this site by looking for an answer why cmake doesn’t honor CMAKE_C_FLAGS.Any flags. Not just fancy -O3 … etc… In my case it just ignores -m64 flag completely. I think plain autotools/configure build system is way better and easier.CMAKE is a fucking piece of shit, which not only hard to use but hard to learn.Go figure out a list of all cmake variables! Is it somewhere? Where?What a pos is invented. I wish people stop using this crap and start writing normal configure files…
> Found this site by looking for an answer why cmake doesn’t honor CMAKE_C_FLAGS.Delete your CMakeCache-file, or check with “ccmake .” inside the build directory which variables are in the cache.> Go figure out a list of all cmake variables! Is it somewhere? Where?Try “cmake –help”. It tells you about, e.g.:cmake –help-variable-listand evencmake –help-variableswhich gives you all documented variables with the documentation.I also see the problem of many undocumented variables and commands, and also some very obscure features, also the syntax can become very nasty. Also, the caching often causes some PITA. Still, I am a more or less happy cmake user…
I can’t stress enough that autotools is a build system for the *user* of a software package (be it an end-user or a distro maintainer). CMake on the other hand makes it practically impossible to casually build a project; so much so that sometimes I don’t even bother and delete tarballs that are CMake-based right away.The compiler support is horrendous, I’m using the Intel C compiler (icc) and need/want specific flags that allow me to build multi-target binaries, there’s simply no way to convince CMake to throw them in. It seems CMAKE_C_FLAGS is merely a wishlist and CMake ignores flags that I want at will and also chucks in the odd flag willy-nilly (-g3 for instance).I just can’t believe it got so much momentum. There ought to be thousands of users (not developers) that feel the same way as I do.
Its 2019 and CMake is still a nightmare to use. Its exasperatingly complex and stubborn. I’m referring to the GUI functionality which is the only way I can use it. Trying to get open source projects to build under Visual Studio is a horrendous experience, which when using CMake is virtually guaranteed to not go nicely. One major gripe which compounds the difficulty is only being able to deal with one project. Switching to a different source folder messes everything up for good. Its as if CMake remembers stuff on a whim and refuses to back down. Its insistence on using full paths is another shortcoming.
Just wanted to join this thread and vent a little.
Here are some pretty simple nested python lists:
quote_chars = [ [“singlequote”, “‘”], [“doublequote”, ‘”‘] ]
magic_chars = [ [“semicolon”, “;”], [“dollar”, “$”] ]
special_chars = quote_chars + magic_chars
It’s not hard to nest lists in python – I just wrote that off the top of my head. Plenty of other languages are similarly easy to write and use. But damn I would hate to write that code in CMAKE. Now imagine having to use CMAKE to do something actually complex