7 ms·

All these CMake improvements are the best example of optimising into a local minimum I have ever seen in SWE

by pharmakom 3y ago

wirthjason 3y ago
Good phrasing! I’m just a hobbyist so I don’t get very involved but what would you suggest as an alternative maximum?
- paulddraper 3y ago
  I assume Bazel
- bluGill 3y ago
  What do you want in a maximum? Cmake is a local maximum if popularity is important, which it should be. Because cmake is popular you can find lots of things that work with it, and when you have problems other experts who can help. For build systems few people really want to become experts so finding them is important. Don't take the above as saying cmake is the best, it deserves most criticism. However the alternatives are probably not compelling just because they are not popular.
  - jcranmer 3y ago
    A build system is largely declarative--it tends to boil down to defining rules like "how to compile a source file", "how to build a library", etc., along with the lists of things those rules need to be applied to, with there being a confusing three-way tug-of-war between the user, the project, and the system over how to override stuff and who wins out. The end result should be that you should ideally be able to query the build system to figure out the underlying declarative pieces of it pretty easily (e.g., list all of the C++ compiler invocations, list all of the package dependencies, etc.). CMake is like halfway there or so, combined with a shell-like language that has some annoying issues (e.g., functions are statements, not expressions, so if you want to do dirname(dirname(foo)), that's two calls to PARENT_PATH). It does a better job than autoconf/make in that it doesn't invite you to resort to shell almost immediately, but that is admittedly a low bar.
    - bluGill 3y ago
      While I want a.build system to be declaritive, in the real world there is always complexity they designers didn't think of. So I need an escape to build something they didn't think of. Though it would be nice if that thing I.build could then be declarative.
- IshKebab 3y ago
  Bazel is the only sensible alternative for C++. It's obviously way more work and not really worth it for really small projects, but it is at least well designed and it solves real problems through hermeticity. But if you're not going to go to that effort I wouldn't really recommend anything other than CMake. There are alternatives that are a bit better (Meson) but then you give up on using the de facto build system (as much as there is one). Also I've found that a lot of the "cleaner" C++ build systems are partly only cleaner because they ignore the full range of complexity that real world C++ builds have to content with. Rpaths, symbol visibility, etc.
- gavinhoward 3y ago
  Disclaimer: I'm making a competing build system. I won't tell you specific build systems, but I will tell you what to look for. Look for power. Unlimited power. [1] Usually, this means a few things: 1. The build system uses a general-purpose language, even if the language needs features to be added. 2. The build system does not reduce the power of the general-purpose language. For example, say it starts with Python but prohibits recursion. In that case, you know it is not unlimited power. Looking at you, Starlark. 3. The build can be dynamically changed, i.e., the build is not statically determined before it even begins. 4. Each task has unlimited power. This means that the task can use a general-purpose language, not just run external processes. 5. And there has to be some thought put it in user experience. Why are these important? Well, let's look at why with CMake, which fails all of them. For #1, CMake's language started as a limited language for enumerating lists. (Hence, CMakeLists.txt is the file name.) And yet, it's grown to be as general-purpose as possible. Why? Because when you need an if statement, nothing else will do, and when you need a loop, nothing else will do. And that brings us to #2: if CMake's language started limited, are there still places where it's limited? I argue yes, and I point to the article where it says that your couldn't dynamically call functions until recently. There are probably other places. For #3, CMake's whole model precludes it. CMake generates the build upfront then expects another build system to actually execute it. There is no changing the build without regenerating it. (And even then, CMake did a poor job until the addition of `--fresh`.) A fully dynamic build should be able to add targets and make others targets depend on those new targets dynamically, among other things. For #4, obviously CMake limits what tasks can do because Ninja and Make limit tasks to running commands. As another example, to implement a LaTeX target, you technically need a while loop to iterate until a fixed point. To do that with Make and Ninja, you have to jump through hoops or use an external script that may not work on all platforms. CMake obviously fails #5, and to see how much other build systems fail it, just look for comments pouring hate on those build systems. CMake fails the most, but I haven't seen one that passes yet. As an example, CMake barely got a debugger. Wow! Cool! It's been 20 years! My build system will have a debugger in public release #2 (one after the MVP) that will be capable of outputting to multiple TTY's like gdb-dashboard. [2] They should have had this years ago! Should other comments suggest specific build systems, like the one that suggested Bazel, judge them by this list. Some will be better than others. None will pass everything, IMO, which is why I'm making my own. [1]: https://youtube.com/watch?v=Sg14jNbBb-8 https://youtube.com/watch?v=Sg14jNbBb-8 [2]: https://github.com/cyrus-and/gdb-dashboard https://github.com/cyrus-and/gdb-dashboard
- rubicks 3y ago
  Use whatever your chosen platform supports "natively". If you're on Linux like me, then use GNU Make or even a Bash script. I'm sure Windows users have something different. Here's the important part: move to a more powerful tool after you decide to support other platforms --- and before circumstances force your hand.
klodolph 3y ago
“Local minimum” is a great way to put it. I recognize that CMake has done a lot to make people’s lives easier, but it has so many design flaws that the entire design seems almost purposefully user-hostile. I know it’s not hostile on purpose, but it sometimes feels that way.
- virtualized 3y ago
  Begin by throwing the language away. Provide a tool that converts existing CMake scripts to the new, sane language. Use an established programming language for the new language.
  - adhesive_wombat 3y ago
    That's basically what CMake already attempted to do: be a sane alternative to figuring out the madness of autoconf and Makefiles.
    - klodolph 3y ago
      The language itself is, in many ways, worse than the shell scripts it replaced with autoconf.
      - adhesive_wombat 3y ago
        I don't disagree that the CMake language is badly misguided. I think that the SCons approach of just writing Python is sensible rather then inventing a whole new scripting language as well as a build system. But CMake probably will get you a program that compiles cross-platform within an hour or two, even for a novice. Autotools probably won't do that for you.
        misnome 3y ago
        SCons is utterly horrible. It isn’t a build system so much as a “Build your own build system” system. It gives you absolutely nothing to manage dependencies or shared information, or cross-platform ways of handling compiler features. As such, everything using it is it’s own unique system completely alien and not interoperable with anything else. And being python seems to lead to people embedding parts of their application as part of the build system, so now that is intertwined also. I will run a million miles if I ever see a project using SCons, CMake is infinitely nicer, and makes some sense but I agree with further up the thread that it needs a new, saner language that maps over the top (expressions would be a start).
rubicks 3y ago
That's the most insightful description of cmake featurism I've ever read. Kitware seems to work tirelessly to reach technical mediocrity.

All these CMake improvements are the best example of optimising into a local minimum I have ever seen in SWE

wirthjason 3y ago

Good phrasing! I’m just a hobbyist so I don’t get very involved but what would you suggest as an alternative maximum?

paulddraper 3y ago
I assume Bazel
bluGill 3y ago
What do you want in a maximum? Cmake is a local maximum if popularity is important, which it should be. Because cmake is popular you can find lots of things that work with it, and when you have problems other experts who can help. For build systems few people really want to become experts so finding them is important. Don't take the above as saying cmake is the best, it deserves most criticism. However the alternatives are probably not compelling just because they are not popular.
- jcranmer 3y ago
  A build system is largely declarative--it tends to boil down to defining rules like "how to compile a source file", "how to build a library", etc., along with the lists of things those rules need to be applied to, with there being a confusing three-way tug-of-war between the user, the project, and the system over how to override stuff and who wins out. The end result should be that you should ideally be able to query the build system to figure out the underlying declarative pieces of it pretty easily (e.g., list all of the C++ compiler invocations, list all of the package dependencies, etc.). CMake is like halfway there or so, combined with a shell-like language that has some annoying issues (e.g., functions are statements, not expressions, so if you want to do dirname(dirname(foo)), that's two calls to PARENT_PATH). It does a better job than autoconf/make in that it doesn't invite you to resort to shell almost immediately, but that is admittedly a low bar.
  - bluGill 3y ago
    While I want a.build system to be declaritive, in the real world there is always complexity they designers didn't think of. So I need an escape to build something they didn't think of. Though it would be nice if that thing I.build could then be declarative.
IshKebab 3y ago
Bazel is the only sensible alternative for C++. It's obviously way more work and not really worth it for really small projects, but it is at least well designed and it solves real problems through hermeticity. But if you're not going to go to that effort I wouldn't really recommend anything other than CMake. There are alternatives that are a bit better (Meson) but then you give up on using the de facto build system (as much as there is one). Also I've found that a lot of the "cleaner" C++ build systems are partly only cleaner because they ignore the full range of complexity that real world C++ builds have to content with. Rpaths, symbol visibility, etc.
gavinhoward 3y ago
Disclaimer: I'm making a competing build system. I won't tell you specific build systems, but I will tell you what to look for. Look for power. Unlimited power. [1] Usually, this means a few things: 1. The build system uses a general-purpose language, even if the language needs features to be added. 2. The build system does not reduce the power of the general-purpose language. For example, say it starts with Python but prohibits recursion. In that case, you know it is not unlimited power. Looking at you, Starlark. 3. The build can be dynamically changed, i.e., the build is not statically determined before it even begins. 4. Each task has unlimited power. This means that the task can use a general-purpose language, not just run external processes. 5. And there has to be some thought put it in user experience. Why are these important? Well, let's look at why with CMake, which fails all of them. For #1, CMake's language started as a limited language for enumerating lists. (Hence, CMakeLists.txt is the file name.) And yet, it's grown to be as general-purpose as possible. Why? Because when you need an if statement, nothing else will do, and when you need a loop, nothing else will do. And that brings us to #2: if CMake's language started limited, are there still places where it's limited? I argue yes, and I point to the article where it says that your couldn't dynamically call functions until recently. There are probably other places. For #3, CMake's whole model precludes it. CMake generates the build upfront then expects another build system to actually execute it. There is no changing the build without regenerating it. (And even then, CMake did a poor job until the addition of `--fresh`.) A fully dynamic build should be able to add targets and make others targets depend on those new targets dynamically, among other things. For #4, obviously CMake limits what tasks can do because Ninja and Make limit tasks to running commands. As another example, to implement a LaTeX target, you technically need a while loop to iterate until a fixed point. To do that with Make and Ninja, you have to jump through hoops or use an external script that may not work on all platforms. CMake obviously fails #5, and to see how much other build systems fail it, just look for comments pouring hate on those build systems. CMake fails the most, but I haven't seen one that passes yet. As an example, CMake barely got a debugger. Wow! Cool! It's been 20 years! My build system will have a debugger in public release #2 (one after the MVP) that will be capable of outputting to multiple TTY's like gdb-dashboard. [2] They should have had this years ago! Should other comments suggest specific build systems, like the one that suggested Bazel, judge them by this list. Some will be better than others. None will pass everything, IMO, which is why I'm making my own. [1]: https://youtube.com/watch?v=Sg14jNbBb-8 https://youtube.com/watch?v=Sg14jNbBb-8 [2]: https://github.com/cyrus-and/gdb-dashboard https://github.com/cyrus-and/gdb-dashboard
rubicks 3y ago
Use whatever your chosen platform supports "natively". If you're on Linux like me, then use GNU Make or even a Bash script. I'm sure Windows users have something different. Here's the important part: move to a more powerful tool after you decide to support other platforms --- and before circumstances force your hand.

klodolph 3y ago

“Local minimum” is a great way to put it. I recognize that CMake has done a lot to make people’s lives easier, but it has so many design flaws that the entire design seems almost purposefully user-hostile. I know it’s not hostile on purpose, but it sometimes feels that way.

virtualized 3y ago
Begin by throwing the language away. Provide a tool that converts existing CMake scripts to the new, sane language. Use an established programming language for the new language.
- adhesive_wombat 3y ago
  That's basically what CMake already attempted to do: be a sane alternative to figuring out the madness of autoconf and Makefiles.
  - klodolph 3y ago
    The language itself is, in many ways, worse than the shell scripts it replaced with autoconf.
    - adhesive_wombat 3y ago
      I don't disagree that the CMake language is badly misguided. I think that the SCons approach of just writing Python is sensible rather then inventing a whole new scripting language as well as a build system. But CMake probably will get you a program that compiles cross-platform within an hour or two, even for a novice. Autotools probably won't do that for you.
      - misnome 3y ago
        SCons is utterly horrible. It isn’t a build system so much as a “Build your own build system” system. It gives you absolutely nothing to manage dependencies or shared information, or cross-platform ways of handling compiler features. As such, everything using it is it’s own unique system completely alien and not interoperable with anything else. And being python seems to lead to people embedding parts of their application as part of the build system, so now that is intertwined also. I will run a million miles if I ever see a project using SCons, CMake is infinitely nicer, and makes some sense but I agree with further up the thread that it needs a new, saner language that maps over the top (expressions would be a start).

rubicks 3y ago

That's the most insightful description of cmake featurism I've ever read. Kitware seems to work tirelessly to reach technical mediocrity.