8 ms·
The recommended compatibility boilerplate for new projects is tedious. There must be a way to include this knowledge in cmake itself rather than requiring every
by tux1968 8y ago
The recommended compatibility boilerplate for new projects is tedious. There must be a way to include this knowledge in cmake itself rather than requiring every "properly" configured project to get this right:
cmake_minimum_required(VERSION 3.1)
if(${CMAKE_VERSION} VERSION_LESS 3.12)
cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION})
else()
cmake_policy(VERSION 3.12)
endif()
This is all before you even start thinking about your own project.
- baby 8y agoThis syntax is also uber ugly. I can’t understand why C still hasn’t a proper build system that is either using convention over configuration (like Go or Rust) or something like cmake but with a proper syntax (maybe something in pyhon?)
- bendmorris 8y agoScons (https://scons.org/ https://scons.org/) is one alternative. The configurations (and Scons itself) are Python.
- electricslpnsld 8y agoScons has soooo many problems. You still can't pass in positional linker flags without completely hacking how it calls the linker. :(
- blattimwind 8y agoConfiguration-by-full-language-by-default is IME a relatively big red flag for things like this. Much rather have a limited configuration language, possibly with the option of going full bore if needed. Case in point, qbs is much more workable. Declarative-glue-predefined-stuff-together most of the way, JavaScript capability if needed.
- wirrbel 8y agoI liked scons but it is what I would consider a legacy project that I would not introduce in new software or actively switch to. If you like scons check out meson, which feels similar I think.
- rleigh 8y agoIt's awful. It's not even a build system; it's a framework to make your own custom special snowflake build system that is unique to your project and which contains 1% of the functionality you get for free with cmake. Take a trivial problem: enabling threading in a cross-platform manner. CMake: "find_package(Threads)" Autotools: "ACX_PTHREAD" SCons: Write it yourself. Now multiply this by every single other detail of your project. It's wheel reinvention writ large, and no one else will have a clue how to build or work on your project.
- Langdal 8y agoSCons is a build system for C and C++ (and some other languages) that is configured in Python. I haven't tried it much though.
- jabl 8y agoMeson seems increasingly popular. Never tried it myself though.
- zeotroph 8y agoThey also went the cmake route of not trying to be the build system, but the meta buildsystem which just writes out ninjafiles, or makefiles and lots of other obscure formats in case of cmake. This is probably also the reason why cmake 'won' so far.
- codedokode 8y agoI think they did it in order not to duplicate make's functionality. Make is useful for partial rebuilds (when you change a single file only it is recompiled). You either use make or have to implement this yourself.
- notriddle 8y agoThey did it because they didn't want to duplicate Ninja's functionality. It does partial rebuilds, it's been heavily optimized for just doing that, and it's a Google-created project that they're already using for other non-Bazel projects.
- zik 8y agoI'm loving meson. I have around a hundred thousand lines of code building with it and it's the cleanest build system I've used yet. Much less obscure than make or cmake.
- fh973 8y agoBazel, the open source sibling of Google's blaze.
- danaur 8y agoI feel like there isn't a community outside of Google that uses Bazel strongly, and therefore it has weak Community Support.
- ur-whale 8y agoYou mean the abomination that requires you to build an entire tree of directories before you write your first line of code and leaves off file droppings all over the place when it runs? Just by looking at the directory structure of a bazel project, you can tell it is the byproduct of a mind that has been warped by Java.
- twic 8y agoI've been recommended Boost.Build, aka b2, the build system Boost uses to build itself, but also usable for any other project: https://boostorg.github.io/build/manual/develop/ https://boostorg.github.io/build/manual/develop/
- LVB 8y agoBeware! At a previous job, Boost Build was easily one of the most unpopular aspects of the tech stack. It had 5% of people evangelizing it, and they were also the only ones who “got” the complicated Jam file arrangement. The rest of us couldn’t stand it. Just way too abstruse IMHO.
- slavik81 8y agoI used Boost Build for years, but I never figured out how to do anything but copy/paste our existing build files. I found scraps of documentation on Jam here and there, but it never made much sense when I looked at our code. I later discovered CMake and found it much, much easier to learn. On an unrelated note, the best comment I have ever come across is related to Boost Build: https://github.com/openembedded/openembedded/blob/fabd8e6d07d3cd0cc93c2a0fc804f8c8f316c649/recipes/boost/boost-with-bjam.inc#L87 https://github.com/openembedded/openembedded/blob/fabd8e6d07...
- jcelerier 8y agoBoost.Build is so good that even Boost is moving to CMake
- rleigh 8y agoDid they also recommend any documentation or examples? Because I've yet to find anything that comes close to the extensive CMake documentation. Heck, even GNU autotools have better docs and examples than b2.
- zeotroph 8y agoThe syntax... `list(GET mylist 4 val)` - oh, you mean `val = mylist[4]`. And the strange `function(ARGUMENTNAME argument1 OTHERARG arg2)` function syntax, and that out value names are always passed into a function as this language does not know `=` assignment, and the semicolon separated lists. And worst of all, the weak to absent typing, reading from a nonsense variable never fails. I hope this is all abstracted enough so one day cmake can become saner to read and write. For now you just have to carry this otherwise useless syntax knowledge with you, or switch to meson or waf. Most IDEs seem to prefer cmake though, especially with the new cmake server mode it might be here to stay. And a big thanks to all the saints who want to make cmake understandable for the rest of us.
- codetrotter 8y agoI’ve used a few different build systems over time. A handful of them I’ve found quite agreeable, others not so much. I once even went as far as writing a rudimentary build system from scratch myself for use in one of my personal projects. In that particular case, implementing my own build system turned out to be the right choice, but I also gained some insight into just how difficult it is to create a good build system so I would like to echo your sentiment about thanking the people that spend time developing fully fledged build systems. I’ve never heard of meson before. A cursory glance at the meson docs is telling me that meson is worth looking into further. Thanks!
- wirrbel 8y agoMeson is likeable and with ninja has a great user experience. I do think it is much easier to understand than cmake (and I have some years of cmake usage under my belt(
- kabdib 8y agoFor a domain-specific language, CMAKE is a total failure at making things clearer and simpler and more reliable. And of course the wizened software engineer in me has to be restrained: "Oh hey, I can make a better build system than that..."
- mianos 8y agoThere is a python one, waf, https://en.m.wikipedia.org/wiki/Waf https://en.m.wikipedia.org/wiki/Waf It is awesome but not very popular. I wish it was more popular. As a python and C++ developer the build files and up so much clearer than anything else. I write and use cmake files every day and I don't like it at all.
- ur-whale 8y agoInteresting, thanks for that. Haven't dug into it yet to say thumbs up or down, but the fact that it uses a full-fledged generic programming language instead of a DSL is a promising start. Here's a waf "makefile": https://gitlab.com/ita1024/waf/blob/master/demos/c++/wscript https://gitlab.com/ita1024/waf/blob/master/demos/c++/wscript
- slavik81 8y agoHave you tried doing anything complex? It's been a long time since I last used Waf, but I found it very difficult to extend.
- mianos 8y agoIt has been a while but I wrote an ARM and Atmel cross build system for Arduino boards. It was hard keeping compatibility with the IDE environment but the result worked and was not half as ugly as a cmake setup.
- orf 8y agoMaybe we need a language that compiles down to CMake!
- goalieca 8y agoWell call it autocmake!
- therein 8y agoLove it. You start with AutoCMakeLists.m4. Yes, m4 macros are back in the game again! Using autocmake, you build that into a CMakeLists.txt. After that now you can use cmake to generate your Makefile. Voila.
- flukus 8y agoI'll create the root makefile that invokes AutoCMake, then CMake, then Make and then all the edge cases CMake can't handle, plus add a much more usable interface.... Take out AutoCMake and it's actually what I'm doing right now. > Yes, m4 macros are back in the game again! Actually, I did some codegen experiments recently and found M4 to be really nice once you get past the bad documentation and actually understand it, along with ignoring any experiences with autotools of course. Besides the general substitutions and macros, the divert/undivert primitives are simple yet this is where the real power of the language is, they easily let you write to a number of named/numbered buffers and then pull them back in where needed. The wikipedia article probably shows this off more clearly than the documentation: https://en.wikipedia.org/wiki/M4_(computer_language) https://en.wikipedia.org/wiki/M4_(computer_language)
- Shorel 8y agoBefore CMake the "proper" thing were ./configure and ./automake scripts which are an atrocity from any point of view. More than "proper", or simply "nice looking syntax" the thing I like from CMake is that a single file makes my project compile in several versions of Linux and Windows using a variety of compilers. Any suitable replacement system should also do this.
- tom_ 8y ago+1,000. CMake may be bad in many respects, and a bit unhelpful in others, but it makes managing multi-platform projects pretty straightforward. There's not much more cruft than you'd expect, and there's convenient support for the standard tools for the major platform - and in exchange for that, I can forgive it quite a lot. And it does actually seems to be improving over time, too, so over time I seem to have to forgive it less, even if still measurably more than not at all. For single-platform projects it's less essential, but I think the PUBLIC/INTERFACE project settings stuff is still a draw, and its support for Ninja build files too.
- gnufx 8y agoTo me autotools have the great advantage that I can make projects using them work relatively easily if they need adjusting in one of the many things I build, and I can write the support for a new project easily. They're pragmatic, and I don't think deserve "atrocity" by any means. In contrast, cmake often causes me to throw up my hands. It's not my experience that cmake projects just work even on GNU/Linux when needing, say, to build shared libraries or install in a different sort of tree. I've used autotools quite painlessly over many years on assorted platforms including in GCC "Canadian cross" (cross-building a cross-compiler -- between GNU/Linux, SunOS, and MS-DOS originally). I did find a new level of horror in bazel when faced with building tensorflow for a different target, despite explicit instructions for a different release.
- Shorel 8y agoYou should write an article detailing your experience with both systems. It should make for an interesting read.
- slavik81 8y agoShake looks promising to me. It has a Haskell front-end, and clearly has had a lot of thought put into it. That said, I have never tried it. Despite CMake's attrocious syntax, the underlying compilation model has always worked more or less as I expected. I can't say that about most of the alternatives I have tried. I was frequently left confused and frustrated by my build systems until I found CMake.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- quietbritishjim 8y agoWhy do this? Why not choose a minimum version that has the features your build system depends on and just leave the first line at the top? It's not like you can use features from the newer version anyway, if you seriously want to support the older version. And if the same line of code has two different meanings in two versions, you want the old meaning (as you would get without target_version(<new version>)) because presumably you wrote your CMakeLists assuming that behaviour. Edit: If I had read TFA before I posted I would've seen that's where the quoted code comes from. As the first thing that it teaches you to put in your CMakeLists.txt that is a pretty unfortunate failure IMO. If an old version of CMake has a behaviour you don't want (such as "wrong linking behavior on macOS" quoted in the linked article) then bite the bullet and use a newer minimum version of CMake. You could do this on only the cases it would cause a problem (e.g. just on MacOS, or just when a cache variable is set) but do so unconditionally of the version, so if someone tries to use an old version of CMake in that configuration they'll get a hard error. That's what you want!
- ur-whale 8y agoWorse, if you try to leave those lines out because just seeing them at the start of every build file, the whole ball of spit an glue pesters you with warnings. Ugh.