5 ms·

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

by tsss 4y ago

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)
      - mdaniel 4y ago
        Heh, this comment reminded me of those "The Tao of ..." - in your case Make; "smack, and the novice was thus enlightened" :-D Based on your PoV, I'm guessing pkg-config is similarly misguided, since those fools allow the end user to specify the prefix, includedir, libdir, and any cflags and ldflags for ther setup. Pssh, idiots. If they'd just "sudo make install" everything, they'd be enlightened > Presumably all of those are tested in CI on each PR? Clearly not "2^26 possibilities," but not "linux/amd64 or gtfo" either: https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.4 https://github.com/keepassxreboot/keepassxc/releases/tag/2.7...
  - palata 4y ago
    I'm fine with autotools, cmake, meson, gradle, ... I don't usually hate tools. I often hate what people do with them, though.
- tsss 4y ago
  You don't have to be an expert to see how bad it is. CMake is as if someone took all the worst parts of C (which isn't particularly good to begin with), namely textual macros, and made a whole language out of it.
  - palata 4y ago
    Because you can make a mess with CMake does not mean it's necessarily terrible. I'm pretty sure I can make a mess with any tool/language. Now to use a tool correctly, you certainly need some basics. Saying that those who manage not to make a mess with a tool are probably doing it wrong because you don't know how to do it feels... weird.

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

by 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.

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)
    - mdaniel 4y ago
      Heh, this comment reminded me of those "The Tao of ..." - in your case Make; "smack, and the novice was thus enlightened" :-D Based on your PoV, I'm guessing pkg-config is similarly misguided, since those fools allow the end user to specify the prefix, includedir, libdir, and any cflags and ldflags for ther setup. Pssh, idiots. If they'd just "sudo make install" everything, they'd be enlightened > Presumably all of those are tested in CI on each PR? Clearly not "2^26 possibilities," but not "linux/amd64 or gtfo" either: https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.4 https://github.com/keepassxreboot/keepassxc/releases/tag/2.7...
- palata 4y ago
  I'm fine with autotools, cmake, meson, gradle, ... I don't usually hate tools. I often hate what people do with them, though.
tsss 4y ago
You don't have to be an expert to see how bad it is. CMake is as if someone took all the worst parts of C (which isn't particularly good to begin with), namely textual macros, and made a whole language out of it.
- palata 4y ago
  Because you can make a mess with CMake does not mean it's necessarily terrible. I'm pretty sure I can make a mess with any tool/language. Now to use a tool correctly, you certainly need some basics. Saying that those who manage not to make a mess with a tool are probably doing it wrong because you don't know how to do it feels... weird.