3 ms·

It blows my mind that CMake is the premier build system for C++. I don't miss that dumpster fire. Too bad that C++ has invested so heavily in modernizing the l

It blows my mind that CMake is the premier build system for C++. I don't miss that dumpster fire. Too bad that C++ has invested so heavily in modernizing the language, but it can't invest in a sane, standard build tool. :(

santaclaus 9y ago
CMake is far more than a build tool.
- noobermin 9y ago
  That doesn't really address their criticism, not that their "dumpster fire" label is very detailed.
- weberc2 9y ago
  That's certainly part of the problem.
  - santaclaus 9y ago
    Or one of its major advantages. Is there another tool that can generate IDE projects, in a cross platform manner, across a wide variety of compilers, operating systems, etc? I'd love to use a tool that looks nicer, but there is nothing (to my knowledge, I'd love to be proven wrong!) that can do what CMake does with the same breadth and transparency.
    - weberc2 9y ago
      > Is there another tool that can generate IDE projects, in a cross platform manner, across a wide variety of compilers, operating systems, etc? You have the problem backwards. IDEs wouldn't need distinct project files if build systems could reasonably describe the project structure out of the box. There is no need for every tool to know about every other tool. This is a solved problem in most modern programming languages.
      - lomnakkus 9y ago
        > This is a solved problem in most modern programming languages. No it's not. Not even close. Just out of curiosity what what's your current IDE?
        weberc2 9y ago
        It absolutely is. My "IDE" is vim. It understands projects in Rust, Purescript, and Go by installing a single plugin. Zero configuration. The same works for VSCode.
        lomnakkus 9y ago
        > It absolutely is. No, it really isn't, but... have fun whatever you're doing. :)
      - geezerjay 9y ago
        > IDEs wouldn't need distinct project files But they do, and ignoring hard constraints imposed by reality doesn't help increase adoption rates. > There is no need for every tool to know about every other tool. If you want your product to be supported by an IDE but you don't have any say on how that IDE is developed, the only sure way you have to get your product supported by that IDE is to get your product to output the IDE project files.
        weberc2 9y ago
        > But they do, and ignoring hard constraints imposed by reality doesn't help increase adoption rates. But they don't, and saying they're "imposed by reality" is not a compelling argument. They need information about a project; there is no reason that information needs to be generated by a build tool instead of the same files that the rest of the toolchain use. They may also need a file to save a user editor preferences, but there is no reason that needs to be the project metadata file. > the only sure way you have to get your product supported by that IDE is to get your product to output the IDE project files. This is patently false. Almost every interesting IDE is pluggable, so a single plugin is written and maintained for each programming language that supports a reasonable project metadata file. CMake is the odd exception which generates files for IDEs because the project metadata is buried in the mess of imperative glue code used to build the project in lieu of a proper build tool.
sclangdon 9y ago
It's interesting that you think CMake is a "dumpster fire". Consider that CMake isn't the only build tool, but has, without question, risen to the top as the premier build tool for C++. Why do you think that is? No doubt you'll say it's because the other options are worse, but I'll just say that I like CMake. I miss CMake when I use other languages and I can set up a complicated project with CMake quicker and easier than I can with other tools. As always, it's what you know.
- weberc2 9y ago
  It's absolutely because the other options for CMake are worse. I don't think my disgust for CMake is entirely predicated on familiarity either--I have much more experience with CMake than I do with Go or Rust's build tools, but I still prefer them. Moreover, as far as I know, none of the new languages are shipping with a fully-imperative, stringly-typed build tool with first class support for dozens of compilers, linkers, package managers, IDEs, version control systems, language libraries, frameworks, precompilers, etc. suggesting they've learned something from hindsight. Instead, the field is narrowing on tools with well-defined responsibilities and interfaces. Instead of knowing about (for example) each compiler, build tools know about a compiler interface that compiler plugins may implement. Instead of writing an imperative script to find your sources, you point your tool to a source directory (if the tool doesn't already assume a convention). Even if 1% of projects need a fully imperative language, it's absurd to foist that on every other project by default. Besides that, I have a lot of criticism for CMake the language, starting with its implicit import mechanism, ridiculous syntax, everything's-a-string, slow execution speed, etc.
boris 9y ago
There is work on a sane build toolchain (build system, package manager, etc) for C++: https://build2.org https://build2.org (full disclosure: I am involved with the project).
- SXX 9y ago
  How is build2 as project planning to maintain packages repository for multiple target operation systems? So far all options for Windows I tested looks failed since they didn't get enough traction for 3rd party contributors to maintain packages and library developers have absolutely no interest. Is using C++ for everything include web interface is sane solution? I could guess reasons for having build bot and web UI in C++, but not sure if it's good way to get more contributors.
- weberc2 9y ago
  I've seen a few "promising" build toolchains; the sad part is that they need to get significant traction to make real progress. Sincerely, best of luck on build2.

santaclaus 9y ago

CMake is far more than a build tool.

noobermin 9y ago
That doesn't really address their criticism, not that their "dumpster fire" label is very detailed.
weberc2 9y ago
That's certainly part of the problem.
- santaclaus 9y ago
  Or one of its major advantages. Is there another tool that can generate IDE projects, in a cross platform manner, across a wide variety of compilers, operating systems, etc? I'd love to use a tool that looks nicer, but there is nothing (to my knowledge, I'd love to be proven wrong!) that can do what CMake does with the same breadth and transparency.
  - weberc2 9y ago
    > Is there another tool that can generate IDE projects, in a cross platform manner, across a wide variety of compilers, operating systems, etc? You have the problem backwards. IDEs wouldn't need distinct project files if build systems could reasonably describe the project structure out of the box. There is no need for every tool to know about every other tool. This is a solved problem in most modern programming languages.
    - lomnakkus 9y ago
      > This is a solved problem in most modern programming languages. No it's not. Not even close. Just out of curiosity what what's your current IDE?
      - weberc2 9y ago
        It absolutely is. My "IDE" is vim. It understands projects in Rust, Purescript, and Go by installing a single plugin. Zero configuration. The same works for VSCode.
        lomnakkus 9y ago
        > It absolutely is. No, it really isn't, but... have fun whatever you're doing. :)
    - geezerjay 9y ago
      > IDEs wouldn't need distinct project files But they do, and ignoring hard constraints imposed by reality doesn't help increase adoption rates. > There is no need for every tool to know about every other tool. If you want your product to be supported by an IDE but you don't have any say on how that IDE is developed, the only sure way you have to get your product supported by that IDE is to get your product to output the IDE project files.
      - weberc2 9y ago
        > But they do, and ignoring hard constraints imposed by reality doesn't help increase adoption rates. But they don't, and saying they're "imposed by reality" is not a compelling argument. They need information about a project; there is no reason that information needs to be generated by a build tool instead of the same files that the rest of the toolchain use. They may also need a file to save a user editor preferences, but there is no reason that needs to be the project metadata file. > the only sure way you have to get your product supported by that IDE is to get your product to output the IDE project files. This is patently false. Almost every interesting IDE is pluggable, so a single plugin is written and maintained for each programming language that supports a reasonable project metadata file. CMake is the odd exception which generates files for IDEs because the project metadata is buried in the mess of imperative glue code used to build the project in lieu of a proper build tool.

sclangdon 9y ago

It's interesting that you think CMake is a "dumpster fire". Consider that CMake isn't the only build tool, but has, without question, risen to the top as the premier build tool for C++. Why do you think that is? No doubt you'll say it's because the other options are worse, but I'll just say that I like CMake. I miss CMake when I use other languages and I can set up a complicated project with CMake quicker and easier than I can with other tools. As always, it's what you know.

weberc2 9y ago
It's absolutely because the other options for CMake are worse. I don't think my disgust for CMake is entirely predicated on familiarity either--I have much more experience with CMake than I do with Go or Rust's build tools, but I still prefer them. Moreover, as far as I know, none of the new languages are shipping with a fully-imperative, stringly-typed build tool with first class support for dozens of compilers, linkers, package managers, IDEs, version control systems, language libraries, frameworks, precompilers, etc. suggesting they've learned something from hindsight. Instead, the field is narrowing on tools with well-defined responsibilities and interfaces. Instead of knowing about (for example) each compiler, build tools know about a compiler interface that compiler plugins may implement. Instead of writing an imperative script to find your sources, you point your tool to a source directory (if the tool doesn't already assume a convention). Even if 1% of projects need a fully imperative language, it's absurd to foist that on every other project by default. Besides that, I have a lot of criticism for CMake the language, starting with its implicit import mechanism, ridiculous syntax, everything's-a-string, slow execution speed, etc.

boris 9y ago

There is work on a sane build toolchain (build system, package manager, etc) for C++: https://build2.org https://build2.org (full disclosure: I am involved with the project).

SXX 9y ago
How is build2 as project planning to maintain packages repository for multiple target operation systems? So far all options for Windows I tested looks failed since they didn't get enough traction for 3rd party contributors to maintain packages and library developers have absolutely no interest. Is using C++ for everything include web interface is sane solution? I could guess reasons for having build bot and web UI in C++, but not sure if it's good way to get more contributors.
weberc2 9y ago
I've seen a few "promising" build toolchains; the sad part is that they need to get significant traction to make real progress. Sincerely, best of luck on build2.