-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake: zlib-ng check failure #228
Comments
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 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? |
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.
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 |
@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 |
I discussed with Earnestly, and we think it's enough to just have consistent way to disable/enable plugins, which So, if I just change stuff like zlib-ng/CMakeLists.txt execute squash/plugins/zlib-ng/CMakeLists.txt Lines 11 to 14 in 26df120
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:The text was updated successfully, but these errors were encountered: