9 ms·

Well well well, we finally found something CMake can actually do. Please, everyone, stop using CMake. It doesn't do its one job.

skohan 6y ago
What's wrong with CMake?
- bluGill 6y ago
  The syntax is weird and inconsistent. Built ins are case insensitive, but user defined functions are sensitive. No way to return values from functions, except by jumping to the scope of the caller and changing its variables unexpectedly. (Better hope you know what the caller does) That isn't a complete list . Despite the above cmake is your best choice of build system for C. Though some competitors could overtake it.
  - andi999 6y ago
    On top of that I found the documentation and the book terrible. I thought it might be easier to understand what it does by reading the source code (didn't try yet)
    - ahartmetz 6y ago
      The documentation is "complete" in the way that some manpages are - the biggest problem with it is the lack of best practices guidance. About books, I believe that good ones exist now. The official CMake book is not among the good ones - last time I checked, it was ridiculously outdated (and IMO not even very good at the time it was written). I have extracted some knowledge from the source code. It's more underdesigned than overdesigned and I think that's the better side to err on. Kinda awkward but you can figure it out.
      - andi999 6y ago
        Which cmake book is good?
        bluGill 6y ago
        Professional cmake seems to be the one recommended now. The author updates it regularly.
  - jmagoon 6y ago
    My least favorite part is how completely impossible it is to discover all the implicit variables set by other cmake files, and there's no common convention, so some libraries are like ${ZLIB_INCLUDE_DIR} and some are #{zLib_INCLUDE_DIRS} and you have to just manually try a bunch of combinations to finally find what works because the scripts themselves use weird string based metaprogramming to build the variables themselves.
  - appleflaxen 6y ago
    which competitors? any thoughts on why are build tools so hard to get right?
    - bluGill 6y ago
      Build2 is one that a coworker of mine likes. There are others. What makes it hard is the problem is a lot deeper than most people realize, so most attempts are not powerful enough to be useful. They are clean until someone points out one of the many edge cases that were not thought of, and by the time you support even a few of them your clean design is a mess of uglyness. Making it worse build systems are an afterthought to most develpers so you end up with a mess just because the programers are not taking care to write good clean code in the build system.
- IshKebab 6y ago
  The language is extremely error prone. It's like they looked at Bash and thought "hmm, too safe". Everything is a string, even lists are just semicolon-separated lists. The argument expansions rules for calling functions are literally impossible to remember. All variables are implicitly defined as empty strings. Typos silently break things. `if` is completely broken. The separation of the configure step from the build step is needlessly confusing and makes some things impossible. This is just scratching the surface. It does have a couple of redeeming qualities: they have a pretty great versioning mechanism which allows them to make breaking changes. Though inexplicably they haven't used it to fix any fundamental flaws, only little tweaks. And most importantly it has been around for ages so loads of the many many weird C++ compilation knobs have been solved.
  - dev_tty01 6y ago
    > It's like they looked at Bash and thought "hmm, too safe". One of my favorite comments in a while. :-)
  - cycloptic 6y ago
    >The separation of the configure step from the build step is needlessly confusing and makes some things impossible. I'm confused. How do you propose CMake supports all those build generators without doing this? (PS. I really don't think the syntax is that bad, aside that it is jarring for C programmers, most complaints are overblown and you get used to it once you learn the rules. It might be interesting if someone made a CMake variant with a less obscure syntax but I don't see much motivation for that to actually happen)
    - kevin_thibedeau 6y ago
      The syntax has improved slightly in recent releases with the target family of commands. You just have to know what legacy parts to avoid which is itself a burden. Still it beats digging into the bowels of autotools. I do fantasize about a new Cmake frontend implemented with Tcl scripting. That would be far more consistent and flexible and you can disable much of the language by default to minimize footbullets then allow commands to be reenabled for times they're needed.
MaxBarraclough 6y ago
I agree that CMake is pretty awful, [0] but I'm not convinced that we'd be better off using its immature competitors, especially considering the fragmentation that would bring. [0] https://news.ycombinator.com/item?id=24203172 https://news.ycombinator.com/item?id=24203172
- ajconway 6y ago
  There seems to be a kind of “network effect” here with CMake, considering how popular it is among C/C++ projects. Meson is more or less equivalent in the functionality it provides. There is also Gradle, but it doesn’t seem to have gained much traction outside of Android development. My personal favorite is Bazel (and others from the Blaze family of build systems). It uses a python-based language for describing build rules, an extensive documentation and developers that respond to issues. Among the downsides is the lack of proper dependency management which is critical for public, open source projects. There is also Nix which takes it even further, but it requires much more involvement from the developer.
  - milanove 6y ago
    Waf is another interesting build system I've seen used in production. It's config is done with Python scripts, which is cool.
    - MaxBarraclough 6y ago
      There's also Premake, [0][1] Buildout, Ninja, SCons, and no doubt there are others. qmake was recently deprecated. It would take a lot to persuade me to move away from CMake and to use something 'non-standard' that few developers are familiar with: * Excellent support for command-line builds on Unix * Excellent support for Visual Studio * Excellent cross-platform package-detection. (Acid test: Can it detect and link against OpenCL without me having to write my own cross-platform OpenCL-detection script?) * Excellent documentation, including clear and consistent best practices and design patterns * A sensible language, whether a scripting language or a declarative language. Must follow the principle of least astonishment and be relatively free of foot-guns. (CMake fails tragically on both counts.) [0] https://premake.github.io/ https://premake.github.io/ [1] https://en.wikipedia.org/wiki/Premake https://en.wikipedia.org/wiki/Premake
mxcrossb 6y ago
I absolutely despise cmake. But autotools is even worse, so it’s what I end up using. I haven’t found another approach which handles my needs.
- andi999 6y ago
  What are the needs
thebruce87m 6y ago
If you’re going to tell us what not to use then at least suggest an alternative.
- knorker 6y ago
  autotools. You may not like it, but it does work. If you like CMake more, that would be a good argument if CMake worked. But it doesn't. So in the choice between the thing that works, and the thing you may like more, please do go with the one that works. E.g. this comment I just wrote: https://news.ycombinator.com/item?id=25702345 https://news.ycombinator.com/item?id=25702345
  - jcelerier 6y ago
    if CMake works for LLVM, Qt, KDE, ReactOS, OpenCV and all the other projects in vcpkg there's some chance it's working for whatever your project is
    - knorker 6y ago
      Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS, with some dependencies in nonstandard locations, etc… etc… It could. But it's an incredible coincidence that it's always cmake projects. Generally on nonstandard installs the others (e.g. scons) won't even run, so portability of the conf is not relevant.
      - jcelerier 6y ago
        > Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS what are you talking about ? take for instance kcachegrind, it builds with cmake and works on every architecture that debian supports (https://packages.debian.org/en/sid/devel/kcachegrind https://packages.debian.org/en/sid/devel/kcachegrind). I also never had issues with x32 when I used it, nor on freebsd. Can't say for openbsd but I'd be surprised it does not work there - this seems to point that other than a minor path issue things just work: https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5-applications-with-cake-on-openbsd/ https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5....
asddubs 6y ago
I'll agree CMake is pretty rough to get into, but what makes you say it doesn't do it's one job?
- knorker 6y ago
  It doesn't produce portable projects. If all you wanted was Linux (or often "Ubuntu compatible") then why not just have a raw Makefile? It doesn't log what it attempted, or why it failed. It can't find out how to link binaries (always awesome to set up som execsnoop (because no logs, remember) only to see that it tries to link with "-llibfoo". In what world could that be correct?. And again it doesn't log how and why it chose that) I could go on, but it's too much for a comment field.
mkl95 6y ago
I have mixed feelings about CMake. Non trivial scripts look like an spaghetti ball, but it's an extremely powerful spaghetti ball.
- cmrdporcupine 6y ago
  From my perspective that's possibly a partially-good thing. Don't do non-trivial things if you can avoid it. Projects should stay on the path of consistent practices, follow standards of packaging, and try to follow conventions that the build system lays out. Stay with standard libraries, avoid custom tooling when possible, etc. If what you're doing requires a boatload of scripting in CMake, you need a good justification for it, and if that justification is there then writing the scripting for the build system is the least of your concerns. But yes it really is ugly once you get off the well beaten track of "here's my source now make a library out of it with a C compiler and a few standard options." I have a personal project I fiddle with that glues together verilator, fusesoc, CMake, a RISC-V compiler toolchain, and some custom scripting into xilinix vivado.. and it terrifies me just a little.
flohofwoe 6y ago
The scripting language is bad, most cmake scripts are much more complex than they should be, but cmake does a lot of things under the hood that make multi- and cross-platform development easier (for example: being able to build with the Visual Studio compiler without running in the "Visual Studio Developer Command Prompt"). A lot of fancy new build tools don't even have proper Windows support.
- knorker 6y ago
  I keep running into CMake based things not being portable, and being broken. And pretty much every single time cmake fails, it does not have ANY log AT ALL of what it did, and why it thinks libfoo is not there. Take autotools. You get EXACTLY what it did, and you see why it failed. With CMake it just goes "you don't have X installed". But I do. It's right there. CMake refuses to say under what cmdline or whatever it tried, and what the error was. Just "X IS NOT THERE!". And then it depends on some version of cmake being installed, which it may not be. I don't do windows coding, but shouldn't autotools be more viable now that Windows ships with bash? But even if not, CMake stuff as a rule is not even portable between different flavors of Unix, so why even use CMake if it's only going to work on Ubuntu more recent than 18.04 or whatever? It's not a silly suggestion. OpenBSD generally just has raw Makefiles.
  - flohofwoe 6y ago
    I've never seen an autotools- or make-based project which builds out of the box on Windows in cmd.exe. Telling people to install cygwin just to build a project simply isn't viable when the default compiler toolchain on Windows is Visual Studio. Also it's not about building projects alone, cmake is also a project file generator for IDEs (in my case that was the actual reason why I switched to cmake from my own project file generator for Visual Studio and Xcode).
    - knorker 6y ago
      Interesting. Why do they fail with autotools?
discardable_dan 6y ago
I still don't understand why cmake/autotools are seriously considered. If you have a tool that is hard to do complex things with (i.e., complex Makefile operations), the solution should _not_ be a tool to generate input for that tool (i.e., CMake/autotools generating makefiles). We shouldn't use a build system whose artifacts are scripts in a cruftier build system; we should replace the universal build system whole-cloth. Even the portability argument fails: if any modifications to the build system require installing the respective meta-tool (cmake/autotools), the generated Makefile is nearly-useless for anyone trying to modify that codebase in any substantial way. We need tools that do the actual building, not Makefile meta-languages.
- knorker 6y ago
  Well, first let me say that I agree that neither cmake nor autotools is perfect. I am saying that cmake is fundamentally broken and unfit for purpose even in addition to what you mention. I've mentioned some in another comment here, but really why cmake should be thrown in the garbage is too long a rant to fit into a comment field. I am VERY interested in hearing new ideas. If you have a truly better way, then I want to use it. Though I'm not sure why you say generating code is so bad. Code gets compiled to machine language, and (especially with optimizations and all the new fancy instructions) are not a thing that most people usually look at anymore. Yes, actual developers need automake/autoconf installed. Of a sufficiently recent version. But what exactly is your suggestion? Autotools at least makes this an issue only for the developers (and not even all of them, since they may not need to change things), not for the orders of magnitude more users. But this is not a unique thing to developers. There may be other generated code. E.g. they need to have protobuf compiler installed, with all the plugins required. End users, even those who build, don't. Developers who don't modify those parts don't. But here's the main thing though: Any portable build system, that already requires EVERY user to have that build system installed, is DoA for being a viable portable build system. It's incredibly frustrating to download a package, only to find that the build system the author in their infinite wisdom chose to use, has not been ported to your platform (or if it has, you have to yak shave for a few hours to get it and its dependencies installed). So you can't compile the thing. The beauty of autotools is that it "compiles" to a "virtual machine" (shell) that will truly run anywhere. Nowadays even on Windows, which now ships bash. CMake too fails on this aspect, in addition to all the other aspects this box won't be able to fit. But please, I truly mean that if you have a better way, then I do want it. It's incredibly hard to build something portable though. Hence the minimal dependency of "just a POSIX shell" for autotools.
rualca 6y ago
> Well well well, we finally found something CMake can actually do. You mean, besides Cmake being the absolute best build system for C and C++ available, right? > Please, everyone, stop using CMake. It doesn't do its one job. What are you talking about? Can you provide a single example where you show Cmake not working?

skohan 6y ago

What's wrong with CMake?

bluGill 6y ago
The syntax is weird and inconsistent. Built ins are case insensitive, but user defined functions are sensitive. No way to return values from functions, except by jumping to the scope of the caller and changing its variables unexpectedly. (Better hope you know what the caller does) That isn't a complete list . Despite the above cmake is your best choice of build system for C. Though some competitors could overtake it.
- andi999 6y ago
  On top of that I found the documentation and the book terrible. I thought it might be easier to understand what it does by reading the source code (didn't try yet)
  - ahartmetz 6y ago
    The documentation is "complete" in the way that some manpages are - the biggest problem with it is the lack of best practices guidance. About books, I believe that good ones exist now. The official CMake book is not among the good ones - last time I checked, it was ridiculously outdated (and IMO not even very good at the time it was written). I have extracted some knowledge from the source code. It's more underdesigned than overdesigned and I think that's the better side to err on. Kinda awkward but you can figure it out.
    - andi999 6y ago
      Which cmake book is good?
      - bluGill 6y ago
        Professional cmake seems to be the one recommended now. The author updates it regularly.
- jmagoon 6y ago
  My least favorite part is how completely impossible it is to discover all the implicit variables set by other cmake files, and there's no common convention, so some libraries are like ${ZLIB_INCLUDE_DIR} and some are #{zLib_INCLUDE_DIRS} and you have to just manually try a bunch of combinations to finally find what works because the scripts themselves use weird string based metaprogramming to build the variables themselves.
- appleflaxen 6y ago
  which competitors? any thoughts on why are build tools so hard to get right?
  - bluGill 6y ago
    Build2 is one that a coworker of mine likes. There are others. What makes it hard is the problem is a lot deeper than most people realize, so most attempts are not powerful enough to be useful. They are clean until someone points out one of the many edge cases that were not thought of, and by the time you support even a few of them your clean design is a mess of uglyness. Making it worse build systems are an afterthought to most develpers so you end up with a mess just because the programers are not taking care to write good clean code in the build system.
IshKebab 6y ago
The language is extremely error prone. It's like they looked at Bash and thought "hmm, too safe". Everything is a string, even lists are just semicolon-separated lists. The argument expansions rules for calling functions are literally impossible to remember. All variables are implicitly defined as empty strings. Typos silently break things. `if` is completely broken. The separation of the configure step from the build step is needlessly confusing and makes some things impossible. This is just scratching the surface. It does have a couple of redeeming qualities: they have a pretty great versioning mechanism which allows them to make breaking changes. Though inexplicably they haven't used it to fix any fundamental flaws, only little tweaks. And most importantly it has been around for ages so loads of the many many weird C++ compilation knobs have been solved.
- dev_tty01 6y ago
  > It's like they looked at Bash and thought "hmm, too safe". One of my favorite comments in a while. :-)
- cycloptic 6y ago
  >The separation of the configure step from the build step is needlessly confusing and makes some things impossible. I'm confused. How do you propose CMake supports all those build generators without doing this? (PS. I really don't think the syntax is that bad, aside that it is jarring for C programmers, most complaints are overblown and you get used to it once you learn the rules. It might be interesting if someone made a CMake variant with a less obscure syntax but I don't see much motivation for that to actually happen)
  - kevin_thibedeau 6y ago
    The syntax has improved slightly in recent releases with the target family of commands. You just have to know what legacy parts to avoid which is itself a burden. Still it beats digging into the bowels of autotools. I do fantasize about a new Cmake frontend implemented with Tcl scripting. That would be far more consistent and flexible and you can disable much of the language by default to minimize footbullets then allow commands to be reenabled for times they're needed.

MaxBarraclough 6y ago

I agree that CMake is pretty awful, [0] but I'm not convinced that we'd be better off using its immature competitors, especially considering the fragmentation that would bring. [0] https://news.ycombinator.com/item?id=24203172 https://news.ycombinator.com/item?id=24203172

ajconway 6y ago
There seems to be a kind of “network effect” here with CMake, considering how popular it is among C/C++ projects. Meson is more or less equivalent in the functionality it provides. There is also Gradle, but it doesn’t seem to have gained much traction outside of Android development. My personal favorite is Bazel (and others from the Blaze family of build systems). It uses a python-based language for describing build rules, an extensive documentation and developers that respond to issues. Among the downsides is the lack of proper dependency management which is critical for public, open source projects. There is also Nix which takes it even further, but it requires much more involvement from the developer.
- milanove 6y ago
  Waf is another interesting build system I've seen used in production. It's config is done with Python scripts, which is cool.
  - MaxBarraclough 6y ago
    There's also Premake, [0][1] Buildout, Ninja, SCons, and no doubt there are others. qmake was recently deprecated. It would take a lot to persuade me to move away from CMake and to use something 'non-standard' that few developers are familiar with: * Excellent support for command-line builds on Unix * Excellent support for Visual Studio * Excellent cross-platform package-detection. (Acid test: Can it detect and link against OpenCL without me having to write my own cross-platform OpenCL-detection script?) * Excellent documentation, including clear and consistent best practices and design patterns * A sensible language, whether a scripting language or a declarative language. Must follow the principle of least astonishment and be relatively free of foot-guns. (CMake fails tragically on both counts.) [0] https://premake.github.io/ https://premake.github.io/ [1] https://en.wikipedia.org/wiki/Premake https://en.wikipedia.org/wiki/Premake

mxcrossb 6y ago

I absolutely despise cmake. But autotools is even worse, so it’s what I end up using. I haven’t found another approach which handles my needs.

andi999 6y ago
What are the needs

thebruce87m 6y ago

If you’re going to tell us what not to use then at least suggest an alternative.

knorker 6y ago
autotools. You may not like it, but it does work. If you like CMake more, that would be a good argument if CMake worked. But it doesn't. So in the choice between the thing that works, and the thing you may like more, please do go with the one that works. E.g. this comment I just wrote: https://news.ycombinator.com/item?id=25702345 https://news.ycombinator.com/item?id=25702345
- jcelerier 6y ago
  if CMake works for LLVM, Qt, KDE, ReactOS, OpenCV and all the other projects in vcpkg there's some chance it's working for whatever your project is
  - knorker 6y ago
    Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS, with some dependencies in nonstandard locations, etc… etc… It could. But it's an incredible coincidence that it's always cmake projects. Generally on nonstandard installs the others (e.g. scons) won't even run, so portability of the conf is not relevant.
    - jcelerier 6y ago
      > Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS what are you talking about ? take for instance kcachegrind, it builds with cmake and works on every architecture that debian supports (https://packages.debian.org/en/sid/devel/kcachegrind https://packages.debian.org/en/sid/devel/kcachegrind). I also never had issues with x32 when I used it, nor on freebsd. Can't say for openbsd but I'd be surprised it does not work there - this seems to point that other than a minor path issue things just work: https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5-applications-with-cake-on-openbsd/ https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5....

asddubs 6y ago

I'll agree CMake is pretty rough to get into, but what makes you say it doesn't do it's one job?

knorker 6y ago
It doesn't produce portable projects. If all you wanted was Linux (or often "Ubuntu compatible") then why not just have a raw Makefile? It doesn't log what it attempted, or why it failed. It can't find out how to link binaries (always awesome to set up som execsnoop (because no logs, remember) only to see that it tries to link with "-llibfoo". In what world could that be correct?. And again it doesn't log how and why it chose that) I could go on, but it's too much for a comment field.

mkl95 6y ago

I have mixed feelings about CMake. Non trivial scripts look like an spaghetti ball, but it's an extremely powerful spaghetti ball.

cmrdporcupine 6y ago
From my perspective that's possibly a partially-good thing. Don't do non-trivial things if you can avoid it. Projects should stay on the path of consistent practices, follow standards of packaging, and try to follow conventions that the build system lays out. Stay with standard libraries, avoid custom tooling when possible, etc. If what you're doing requires a boatload of scripting in CMake, you need a good justification for it, and if that justification is there then writing the scripting for the build system is the least of your concerns. But yes it really is ugly once you get off the well beaten track of "here's my source now make a library out of it with a C compiler and a few standard options." I have a personal project I fiddle with that glues together verilator, fusesoc, CMake, a RISC-V compiler toolchain, and some custom scripting into xilinix vivado.. and it terrifies me just a little.

flohofwoe 6y ago

The scripting language is bad, most cmake scripts are much more complex than they should be, but cmake does a lot of things under the hood that make multi- and cross-platform development easier (for example: being able to build with the Visual Studio compiler without running in the "Visual Studio Developer Command Prompt"). A lot of fancy new build tools don't even have proper Windows support.

knorker 6y ago
I keep running into CMake based things not being portable, and being broken. And pretty much every single time cmake fails, it does not have ANY log AT ALL of what it did, and why it thinks libfoo is not there. Take autotools. You get EXACTLY what it did, and you see why it failed. With CMake it just goes "you don't have X installed". But I do. It's right there. CMake refuses to say under what cmdline or whatever it tried, and what the error was. Just "X IS NOT THERE!". And then it depends on some version of cmake being installed, which it may not be. I don't do windows coding, but shouldn't autotools be more viable now that Windows ships with bash? But even if not, CMake stuff as a rule is not even portable between different flavors of Unix, so why even use CMake if it's only going to work on Ubuntu more recent than 18.04 or whatever? It's not a silly suggestion. OpenBSD generally just has raw Makefiles.
- flohofwoe 6y ago
  I've never seen an autotools- or make-based project which builds out of the box on Windows in cmd.exe. Telling people to install cygwin just to build a project simply isn't viable when the default compiler toolchain on Windows is Visual Studio. Also it's not about building projects alone, cmake is also a project file generator for IDEs (in my case that was the actual reason why I switched to cmake from my own project file generator for Visual Studio and Xcode).
  - knorker 6y ago
    Interesting. Why do they fail with autotools?

discardable_dan 6y ago

I still don't understand why cmake/autotools are seriously considered. If you have a tool that is hard to do complex things with (i.e., complex Makefile operations), the solution should _not_ be a tool to generate input for that tool (i.e., CMake/autotools generating makefiles). We shouldn't use a build system whose artifacts are scripts in a cruftier build system; we should replace the universal build system whole-cloth. Even the portability argument fails: if any modifications to the build system require installing the respective meta-tool (cmake/autotools), the generated Makefile is nearly-useless for anyone trying to modify that codebase in any substantial way. We need tools that do the actual building, not Makefile meta-languages.

knorker 6y ago
Well, first let me say that I agree that neither cmake nor autotools is perfect. I am saying that cmake is fundamentally broken and unfit for purpose even in addition to what you mention. I've mentioned some in another comment here, but really why cmake should be thrown in the garbage is too long a rant to fit into a comment field. I am VERY interested in hearing new ideas. If you have a truly better way, then I want to use it. Though I'm not sure why you say generating code is so bad. Code gets compiled to machine language, and (especially with optimizations and all the new fancy instructions) are not a thing that most people usually look at anymore. Yes, actual developers need automake/autoconf installed. Of a sufficiently recent version. But what exactly is your suggestion? Autotools at least makes this an issue only for the developers (and not even all of them, since they may not need to change things), not for the orders of magnitude more users. But this is not a unique thing to developers. There may be other generated code. E.g. they need to have protobuf compiler installed, with all the plugins required. End users, even those who build, don't. Developers who don't modify those parts don't. But here's the main thing though: Any portable build system, that already requires EVERY user to have that build system installed, is DoA for being a viable portable build system. It's incredibly frustrating to download a package, only to find that the build system the author in their infinite wisdom chose to use, has not been ported to your platform (or if it has, you have to yak shave for a few hours to get it and its dependencies installed). So you can't compile the thing. The beauty of autotools is that it "compiles" to a "virtual machine" (shell) that will truly run anywhere. Nowadays even on Windows, which now ships bash. CMake too fails on this aspect, in addition to all the other aspects this box won't be able to fit. But please, I truly mean that if you have a better way, then I do want it. It's incredibly hard to build something portable though. Hence the minimal dependency of "just a POSIX shell" for autotools.

rualca 6y ago

> Well well well, we finally found something CMake can actually do. You mean, besides Cmake being the absolute best build system for C and C++ available, right? > Please, everyone, stop using CMake. It doesn't do its one job. What are you talking about? Can you provide a single example where you show Cmake not working?