3 ms·

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/keepa

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

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