14 ms·

It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake, now there need to be two more languages (slide 13) that

It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake, now there need to be two more languages (slide 13) that must be understood? It's been 9 years since Modern CMake came out, and I'd estimate adoption at 50-50. This deck does not address the drawbacks of doing this at all, and the only recognition of this problem is in "Stretch Goal: Research development of tool(s) to translate legacy CMake to new CMake language." The current CMake language is fine. Nothing amazing, but good enough. But every moment that I spend configuring CMake is a moment I don't spend doing something actually useful. I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it.

simplotek 4y ago
> It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake (...) No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style. I'd go as far as claiming that 95% of all use cases boil down to simple straight-forward one-liners with modern cmake, with the remaining 5% corresponding to putting together custom cmake find modules, packaging, and deploying runtime dependencies. > (...) now there need to be two more languages (slide 13) (...) I'd argue that if anyone feels the need to write scripts to do something in cmake, they are already doing something awfully wrong to start with.
- chrsig 4y ago
  > No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style. "made obsolete" != expunged from codebases. I'm sure there are plenty using cmake 2.x conventions that haven't been updated, and need maintaining. And in order to either maintain or upgrade, one needs to know both conventions.
  - simplotek 4y ago
    > And in order to either maintain or upgrade, one needs to know both conventions. No, not really. You only need to know the declarative, target-based modern cmake. Most of the ad-hoc nonsense done with legacy cmake is either features that since the 2.x days were added to cmake, or nonsense that should never have been written to start with.
    - bdavis__ 4y ago
      But you still have to deal with it. It exists!!
    - chrsig 4y ago
      You're missing the point -- it was written and still exists, and still needs to either be maintained or re-written. You can't do either of those things if you don't understand it.
      - simplotek 4y ago
        > You're missing the point -- it was written and still exists, No you're completely missing the point. If it exists and needs to be managed then anyone in their right mind migrates their cmake project to modern cmake. Why? Because odds are any weird thing happening in legacy cmake projects happened because either cmake didn't supported things way back then or old timers made a mess for themselves, needlessly. Maintaining code does not require you to keep messes around. You're expected to pay legacy debt, learn from mistakes, and right whatever wrongs you made. With cmake projects, this means modern cmake. No excuse. > and still needs to either be maintained or re-written. It's not a "or". No one forces you to not fix mistakes. You only keep them around if you wish to, and if that's your own personal decision then the responsibility of creating that problem is on you, not on the tooling. I'm talking from experience. I've maintained a dozen or so legacy C++ projects, some of which with auto tools, qmake, and the deprecated imperative cmake style put together over a decade ago. Porting stuff to modern cmake is trivial. There is no excuse.
    - kjs3 4y ago
      What a fascinating planet you must live on where legacy doesn't exist, or if it does developers can see into the future and know what will be 'nonsense' in 10 years time, or make the whole thing moot because of course they rewrite their build framework for every release of the build system, having unlimited resources at hand. Must be nice there.
- palata 4y ago
  This ^. I seems common for people to try to have CMake run Python scripts, install stuff on the system, and do all sorts of custom tasks. I'm sure other build systems also allow devs to make a mess if they want to. Maybe some are less powerful, so that people cannot make such a mess even if they want to. But "the tool is too powerful, I will shoot myself in the foot because I don't want to learn the basics" does not sound like a good argument to me.
  - KurvaKing 4y ago
chrsig 4y ago
> It's been 9 years since Modern CMake came out, and I'd estimate adoption at 50-50. > The current CMake language is fine. Nothing amazing, but good enough. I'd argue these two statements are in conflict. I came to c/c++ after several other languages and ecosystems -- the c++ dependency/build ecosystem is by far the worst. CMake does work. It's underlying capabilities are great, even. But "modern cmake" is sort of a joke syntactically. Generator expressions are indecipherable. Semicolon delimited arrays, no distinguishing between input/output variables... I personally would love for a different DSL frontend to CMake. > I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it. I have to agree with this. The underlying core of cmake is actually pretty awesome. Modern cmake is an improvement in capability. The team deserves credit for that.
- TillE 4y ago
  > But "modern cmake" is sort of a joke syntactically. Generator expressions are indecipherable. Yeah. CMake works, it can do everything you want somehow, but it's a total mess, and the documentation isn't great. Just a simple wrapper API (like libcurl-easy, for example) would go a long way.
  - palata 4y ago
    > the documentation isn't great. I completely disagree, I almost always find what I need in the docs. > Just a simple wrapper API IMO, just spending a couple of hours learning the basics would go a long way. Usually that is not done.
mort96 4y ago
The absolutely atrocious current cmake language (where you can't even make a list of strings! The ONE THING a make replacement should fix!), in combination with the prevalence of legacy cmake everywhere (even in Find*.cmake files distributed by cmake!), are the two primary reasons why I'm using and rooting for Meson over CMake. But its biggest issue, arguably, is the extreme proliferation of bad information. Everything on StackOverflow and similar sites is outdated and bad practice for the most part. You're right that introducing a new language which deprecates the old will make this an even bigger issue.
StreamBright 4y ago
I just don't get the hype around make/CMake/autotools. I usually implement the build tool in the language I am working on (build.py for Python, etc.). It seems that Zig[1] also follows this. What am I missing? 1. https://ziglearn.org/chapter-3/ https://ziglearn.org/chapter-3/
- Izkata 4y ago
  I don't know about the other two, but the recent resurgence of "make" seems to be around using it as a standard interface for running tasks. For example, "make build" would run build.py in a python project, webpack in a javascript project, etc. Similarly there's things that have been ad-hoc standards forever, like "make clean" to remove all build and test artifacts, or "make test" for running tests. Many of my coworkers only use it in this way and are unaware make looks at files/timestamps.
- catiopatio 4y ago
  > What am I missing? The irony of using “hype” to describe make/CMake/autotools while referencing Zig as an alternative example. Building a build tool written in C or C++ requires a build tool — hence the existence of make/CMake/autotools, which can bootstrap themselves from a minimal environment.
  - StreamBright 4y ago
    If I was referencing Zig az the __only__ alternative I would agree. What I wanted to say is to use the same language / tool that your projects uses. Maybe it is impossible for C/C++ as some comments pointed out.
- Koshkin 4y ago
  This is the sanest idea of all, it seems. C++ could easily have a library of build and dependency-tracking classes with a sensible API. Then you could use anything you want in your build "script" that C++ has to offer and not have to jump through hoops to accommodate the most complicated use cases. (And no, you would not be needing a build script for your build tool.)
throwaway894345 4y ago
> The current CMake language is fine. Nothing amazing, but good enough. Lol CMake was a huge reason I got out of C++ development almost a decade ago. I was tired of scripting my own shitty build systems, especially ones which couldn't even manage packages. I never actually need the power CMake offers, but the stuff I do need (reproducible package management) CMake punted on. 99.9% of the time, all you need is a build tool that takes a list of dependencies and a lockfile (or similar).
- jcelerier 4y ago
  > 99.9% of the time, all you need is a build tool that takes a list of dependencies and a lockfile (or similar). I'm very happy for you but almost all the C++ projects I've worked on have needed muuuuuuch more complex build system scripting than this.
  - cogman10 4y ago
    The question you should be asking yourself is "why? why does my C++ project need 18 programming languages to build and java needs an xml file, javascript some json, or rust a toml file".
    - throwaway894345 4y ago
      In fairness, many of the CMake criticisms also apply to Gradle in the Java world, but yeah, Go just needs its go.mod file, Rust just needs its Cargo.toml file.
      - palata 4y ago
        I would argue that Gradle is fine, just like CMake is :-). But there is a philosophical question here: I think that developers should master their basic tools to the point where they don't make a mess writing a CMakeLists.txt or a build.gradle. It feels like many devs think that a tool is too complex if you need to learn it.
      - vlovich123 4y ago
liquidify 4y ago
Cmake is terrible to use.
tsss 4y ago
> CMake is awesome software No, CMake is terrible. It is in fact quite a feat how god damn terrible it manages to be.
- palata 4y ago
  Are you a CMake expert, or are you rather not really good at it? Just to see if there is a correlation between "I don't know how to use it properly" and "I hate it" =).
  - hedora 4y ago
    I have spent more time screwing with cmake than learning multiple other (actually useful) languages that I am an expert at. I have built cmake systems from scratch and replaced others with vanilla make. I am currently stuck dealing with a cmake project that would make all of Byzantium blush. I agree that cmake is terrible. The more I learn to use it properly, the more I hate it. In addition: If you think cmake is solving any problems that vanilla make does not handle better, then either (1) you don't understand how to build and package software, or (2) haven't spent an hour or two reading the gnu make manual and "recursive make considered harmful".
    - mdaniel 4y ago
      I shudder to think at the Makefile which would re-implement this: https://github.com/keepassxreboot/keepassxc/blob/2.7.4/CMakeLists.txt https://github.com/keepassxreboot/keepassxc/blob/2.7.4/CMake... I guess a bazillion QRCODE_INC := $(shell pkg-config --cflags qrencode || true) # or whatever the make version of this is: $(if $(QRCODE_INC), ohgawd, ,)
      - hedora 4y ago
        I got to line 300, and counted > 2^26 possible build configurations, then got bored. Presumably all of those are tested in CI on each PR? The cmake you linked to is a classic example of the "not knowing how to build or package software" cmake anti-pattern. As for QRCODE_INC, I'm guessing that it is just an include directory. Put qrcode.h in /use/include, (or /usr/local/include, or wherever the compiler looks by default) or set an environment variable to tell the build to look in nonstandard paths before looking in system directories. Problem completely solved. (Objection one: What if the installer for qrcode.h puts the header in a strange place? Solution: Fix libqrcode's package.) (Objection two: I don't want to pollute standard paths with conflicting library versions, and can't be bothered to set environment variable overrides. Solution: Docker)

simplotek 4y ago

> It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake (...) No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style. I'd go as far as claiming that 95% of all use cases boil down to simple straight-forward one-liners with modern cmake, with the remaining 5% corresponding to putting together custom cmake find modules, packaging, and deploying runtime dependencies. > (...) now there need to be two more languages (slide 13) (...) I'd argue that if anyone feels the need to write scripts to do something in cmake, they are already doing something awfully wrong to start with.

chrsig 4y ago
> No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style. "made obsolete" != expunged from codebases. I'm sure there are plenty using cmake 2.x conventions that haven't been updated, and need maintaining. And in order to either maintain or upgrade, one needs to know both conventions.
- simplotek 4y ago
  > And in order to either maintain or upgrade, one needs to know both conventions. No, not really. You only need to know the declarative, target-based modern cmake. Most of the ad-hoc nonsense done with legacy cmake is either features that since the 2.x days were added to cmake, or nonsense that should never have been written to start with.
  - bdavis__ 4y ago
    But you still have to deal with it. It exists!!
  - chrsig 4y ago
    You're missing the point -- it was written and still exists, and still needs to either be maintained or re-written. You can't do either of those things if you don't understand it.
    - simplotek 4y ago
      > You're missing the point -- it was written and still exists, No you're completely missing the point. If it exists and needs to be managed then anyone in their right mind migrates their cmake project to modern cmake. Why? Because odds are any weird thing happening in legacy cmake projects happened because either cmake didn't supported things way back then or old timers made a mess for themselves, needlessly. Maintaining code does not require you to keep messes around. You're expected to pay legacy debt, learn from mistakes, and right whatever wrongs you made. With cmake projects, this means modern cmake. No excuse. > and still needs to either be maintained or re-written. It's not a "or". No one forces you to not fix mistakes. You only keep them around if you wish to, and if that's your own personal decision then the responsibility of creating that problem is on you, not on the tooling. I'm talking from experience. I've maintained a dozen or so legacy C++ projects, some of which with auto tools, qmake, and the deprecated imperative cmake style put together over a decade ago. Porting stuff to modern cmake is trivial. There is no excuse.
  - kjs3 4y ago
    What a fascinating planet you must live on where legacy doesn't exist, or if it does developers can see into the future and know what will be 'nonsense' in 10 years time, or make the whole thing moot because of course they rewrite their build framework for every release of the build system, having unlimited resources at hand. Must be nice there.
palata 4y ago
This ^. I seems common for people to try to have CMake run Python scripts, install stuff on the system, and do all sorts of custom tasks. I'm sure other build systems also allow devs to make a mess if they want to. Maybe some are less powerful, so that people cannot make such a mess even if they want to. But "the tool is too powerful, I will shoot myself in the foot because I don't want to learn the basics" does not sound like a good argument to me.
- KurvaKing 4y ago

chrsig 4y ago

> It's been 9 years since Modern CMake came out, and I'd estimate adoption at 50-50. > The current CMake language is fine. Nothing amazing, but good enough. I'd argue these two statements are in conflict. I came to c/c++ after several other languages and ecosystems -- the c++ dependency/build ecosystem is by far the worst. CMake does work. It's underlying capabilities are great, even. But "modern cmake" is sort of a joke syntactically. Generator expressions are indecipherable. Semicolon delimited arrays, no distinguishing between input/output variables... I personally would love for a different DSL frontend to CMake. > I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it. I have to agree with this. The underlying core of cmake is actually pretty awesome. Modern cmake is an improvement in capability. The team deserves credit for that.

TillE 4y ago
> But "modern cmake" is sort of a joke syntactically. Generator expressions are indecipherable. Yeah. CMake works, it can do everything you want somehow, but it's a total mess, and the documentation isn't great. Just a simple wrapper API (like libcurl-easy, for example) would go a long way.
- palata 4y ago
  > the documentation isn't great. I completely disagree, I almost always find what I need in the docs. > Just a simple wrapper API IMO, just spending a couple of hours learning the basics would go a long way. Usually that is not done.

mort96 4y ago

The absolutely atrocious current cmake language (where you can't even make a list of strings! The ONE THING a make replacement should fix!), in combination with the prevalence of legacy cmake everywhere (even in Find*.cmake files distributed by cmake!), are the two primary reasons why I'm using and rooting for Meson over CMake. But its biggest issue, arguably, is the extreme proliferation of bad information. Everything on StackOverflow and similar sites is outdated and bad practice for the most part. You're right that introducing a new language which deprecates the old will make this an even bigger issue.

StreamBright 4y ago

I just don't get the hype around make/CMake/autotools. I usually implement the build tool in the language I am working on (build.py for Python, etc.). It seems that Zig[1] also follows this. What am I missing? 1. https://ziglearn.org/chapter-3/ https://ziglearn.org/chapter-3/

Izkata 4y ago
I don't know about the other two, but the recent resurgence of "make" seems to be around using it as a standard interface for running tasks. For example, "make build" would run build.py in a python project, webpack in a javascript project, etc. Similarly there's things that have been ad-hoc standards forever, like "make clean" to remove all build and test artifacts, or "make test" for running tests. Many of my coworkers only use it in this way and are unaware make looks at files/timestamps.
catiopatio 4y ago
> What am I missing? The irony of using “hype” to describe make/CMake/autotools while referencing Zig as an alternative example. Building a build tool written in C or C++ requires a build tool — hence the existence of make/CMake/autotools, which can bootstrap themselves from a minimal environment.
- StreamBright 4y ago
  If I was referencing Zig az the __only__ alternative I would agree. What I wanted to say is to use the same language / tool that your projects uses. Maybe it is impossible for C/C++ as some comments pointed out.
Koshkin 4y ago
This is the sanest idea of all, it seems. C++ could easily have a library of build and dependency-tracking classes with a sensible API. Then you could use anything you want in your build "script" that C++ has to offer and not have to jump through hoops to accommodate the most complicated use cases. (And no, you would not be needing a build script for your build tool.)

throwaway894345 4y ago

> The current CMake language is fine. Nothing amazing, but good enough. Lol CMake was a huge reason I got out of C++ development almost a decade ago. I was tired of scripting my own shitty build systems, especially ones which couldn't even manage packages. I never actually need the power CMake offers, but the stuff I do need (reproducible package management) CMake punted on. 99.9% of the time, all you need is a build tool that takes a list of dependencies and a lockfile (or similar).

jcelerier 4y ago
> 99.9% of the time, all you need is a build tool that takes a list of dependencies and a lockfile (or similar). I'm very happy for you but almost all the C++ projects I've worked on have needed muuuuuuch more complex build system scripting than this.
- cogman10 4y ago
  The question you should be asking yourself is "why? why does my C++ project need 18 programming languages to build and java needs an xml file, javascript some json, or rust a toml file".
  - throwaway894345 4y ago
    In fairness, many of the CMake criticisms also apply to Gradle in the Java world, but yeah, Go just needs its go.mod file, Rust just needs its Cargo.toml file.
    - palata 4y ago
      I would argue that Gradle is fine, just like CMake is :-). But there is a philosophical question here: I think that developers should master their basic tools to the point where they don't make a mess writing a CMakeLists.txt or a build.gradle. It feels like many devs think that a tool is too complex if you need to learn it.
    - vlovich123 4y ago

liquidify 4y ago

Cmake is terrible to use.

tsss 4y ago

> CMake is awesome software No, CMake is terrible. It is in fact quite a feat how god damn terrible it manages to be.

palata 4y ago
Are you a CMake expert, or are you rather not really good at it? Just to see if there is a correlation between "I don't know how to use it properly" and "I hate it" =).
- hedora 4y ago
  I have spent more time screwing with cmake than learning multiple other (actually useful) languages that I am an expert at. I have built cmake systems from scratch and replaced others with vanilla make. I am currently stuck dealing with a cmake project that would make all of Byzantium blush. I agree that cmake is terrible. The more I learn to use it properly, the more I hate it. In addition: If you think cmake is solving any problems that vanilla make does not handle better, then either (1) you don't understand how to build and package software, or (2) haven't spent an hour or two reading the gnu make manual and "recursive make considered harmful".
  - mdaniel 4y ago
    I shudder to think at the Makefile which would re-implement this: https://github.com/keepassxreboot/keepassxc/blob/2.7.4/CMakeLists.txt https://github.com/keepassxreboot/keepassxc/blob/2.7.4/CMake... I guess a bazillion QRCODE_INC := $(shell pkg-config --cflags qrencode || true) # or whatever the make version of this is: $(if $(QRCODE_INC), ohgawd, ,)
    - hedora 4y ago
      I got to line 300, and counted > 2^26 possible build configurations, then got bored. Presumably all of those are tested in CI on each PR? The cmake you linked to is a classic example of the "not knowing how to build or package software" cmake anti-pattern. As for QRCODE_INC, I'm guessing that it is just an include directory. Put qrcode.h in /use/include, (or /usr/local/include, or wherever the compiler looks by default) or set an environment variable to tell the build to look in nonstandard paths before looking in system directories. Problem completely solved. (Objection one: What if the installer for qrcode.h puts the header in a strange place? Solution: Fix libqrcode's package.) (Objection two: I don't want to pollute standard paths with conflicting library versions, and can't be bothered to set environment variable overrides. Solution: Docker)