Open Earnestly opened 7 years ago
Currently trying to build squash with just my system libs and while most libraries seem to be incorrectly enabled
Most libraries don't have system-wide installs; a lot of them only exist as one .c and one .h file, and are intended to simply be dropped into another code base.
Unless it has been disabled, the build system will always attempt to build the plugin. System-wide installations will be used when available, but if you don't want to enable a plugin you'll have to explicitly disable it.
zlib-ng still seems to be causing issues:
zlib-ng doesn't have the option of using a system-wide install; AFAIK zlib-ng installs are indistinguishable from zlib installs, and zlib and zlib-ng aren't parallel-installable; if you have a system-wide installation it will probably be picked up by the zlib plugin.
The error you pasted occurs when the zlib-ng plugin attempts to read the zconf.h.in file from the zlib-ng submodule in plugins/zlib-ng/zlib-ng. If you haven't checked out submodules, or somehow removed that file, it will fail. The relevant code is at plugins/zlib-ng/CMakeLists.txt.
If you can provide some more details about your use case perhaps we could find a way to accommodate it…
I don't mind that some of the plugins will need to be local but why is it that only zlib-ng causes the configure (cmake) phase to outright fail?
If zlib-ng is not vital to the build then why not have its support be disabled instead?
I don't mind that some of the plugins will need to be local but why is it that only zlib-ng causes the configure (cmake) phase to outright fail?
It shouldn't, unless that file is missing. The file shouldn't be missing unless something has happened to it (or you didn't check out submodules, but that should cause lots of errors earlier on). If you can provide the command(s) to reproduce it from a fresh checkout I'd be happy to take a look, but I'm not seeing the problem here.
If zlib-ng is not vital to the build then why not have its support be disabled instead?
Not sure what you're asking here… are you proposing that plugins without system-wide installs be disabled by default?
I'm not pulling in dozens of submodules I'm not going to use...
I'm trying to suggest that the build system should gracefully avoid building in support for files (or whatever means of detection it uses) it cannot detect, system-wide or otherwise.
I should also be able to explicitly set -DENABLE_ZLIB_NG=OFF
and not have cmake attempt to find zlib-ng...
@nemequ Would you accept patch for explicitly disabling or forcing plugins to be linked systemwide? Detection based in-source builds are sort of counter-productive for distro packagers that try to assure everything is linked systemwide (I've made this same mistake as well in one of my projects).
@nemequ Would you accept patch for explicitly disabling or forcing plugins to be linked systemwide? Detection based in-source builds are sort of counter-productive for distro packagers that try to assure everything is linked systemwide (I've made this same mistake as well in one of my projects).
Obviously it depends on the patch, but in principle yes. I don't think a global flag would work, though--you would have to disable detection on a per-module basis since many (most?) modules don't have a system-installed option.
It probably wouldn't be all that difficult; you'd probably just need to add a bit of logic to cmake/SquashPlugin.cmake
.
I discussed with Earnestly, and we think it's enough to just have consistent way to disable/enable plugins, which cmake/SquashPlugin.cmake
already provides. The problem here just seems to be that squash fails to build if submodules for some plugins haven't been cloned, even if you decide to not use those plugins.
So, if I just change stuff like zlib-ng/CMakeLists.txt execute https://github.com/quixdb/squash/blob/26df120df352af392fd4431f05c6f1de63390753/plugins/zlib-ng/CMakeLists.txt#L11-L14 these lines conditionally depending on ENABLE_ZLIB_NG after call to squash_plugin?
I would imagine some more pedantic distro packagers still want systemwide only option, which could probably be something along throwing error at https://github.com/quixdb/squash/blob/master/cmake/SquashPlugin.cmake#L49 if pkg-config did not find anything. Packagers can disable plugin explicitly if they don't want to package it systemwide. The plugins which don't provide system-wide install option would have to be explicitly disabled as well (less heuristics, automation and surprises the better I think).
This latter is not requirement for this issue however, so do you think I should only fix the current plugins that fail on non cloned submodule?
Currently trying to build squash with just my system libs and while most libraries seem to be incorrectly enabled, perhaps requiring that I manually
--disable-
each one I don't have, zlib-ng still seems to be causing issues: