quixdb / squash

Compression abstraction library and utilities
https://quixdb.github.io/squash/
MIT License
405 stars 53 forks source link

cmake: zlib-ng check failure #228

Open Earnestly opened 7 years ago

Earnestly commented 7 years ago

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:

% ./configure --prefix=/usr --disable-zlib-ng --disable-brieflz --disable-brotli
-- Found CppCheck: /usr/bin/cppcheck (found version "1.79") 
-- bsc plugin: enabled
-- bzip2 plugin: using external library
-- copy plugin: enabled
-- crush plugin: enabled
-- csc plugin: disabled
-- density plugin: disabled
-- doboz plugin: disabled
-- fari plugin: enabled
-- Could NOT find FASTLZ (missing:  FASTLZ_INCLUDE_DIR FASTLZ_LIBRARIES) 
-- fastlz plugin: enabled
-- gipfeli plugin: enabled
-- heatshrink plugin: enabled
-- libdeflate plugin: enabled
-- Checking for module 'liblz4'
--   Found liblz4, version 1.7.5
-- lz4 plugin: using external library
-- Checking for module 'liblzf'
--   Package 'liblzf', required by 'virtual:world', not found
-- lzf plugin: enabled
-- lzfse plugin: enabled
-- lzg plugin: enabled
-- lzham plugin: enabled
-- lzjb plugin: enabled
-- lzma plugin: using external library
-- lzo plugin: using external library
-- miniz plugin: enabled
-- ms-compress plugin: enabled
-- ncompress plugin: enabled
-- quicklz plugin: enabled
-- snappy plugin: using external library
-- wflz plugin: enabled
-- yalz77 plugin: enabled
-- zlib plugin: using external library
CMake Error at plugins/zlib-ng/CMakeLists.txt:6 (file):
  file failed to open for reading (No such file or directory):

    /home/earnest/build/pkgbuilds/squash-git/src/squash/plugins/zlib-ng/zlib-ng/zconf.h.in
Call Stack (most recent call first):
  plugins/zlib-ng/CMakeLists.txt:11 (generate_cmakein)

CMake Error: File /home/earnest/build/pkgbuilds/squash-git/src/squash/plugins/zlib-ng/zconf.h.cmakein does not exist.
CMake Error at plugins/zlib-ng/CMakeLists.txt:13 (configure_file):
  configure_file Problem configuring file

-- zlib-ng plugin: disabled
-- zling plugin: enabled
-- Could NOT find ZPAQ (missing:  ZPAQ_INCLUDE_DIR ZPAQ_LIBRARIES) 
-- zpaq plugin: enabled
-- Checking for module 'libzstd'
--   Found libzstd, version 1.1.4
-- zstd plugin: using external library
-- Configuring incomplete, errors occurred!
See also "/home/earnest/build/pkgbuilds/squash-git/src/squash/CMakeFiles/CMakeOutput.log".
See also "/home/earnest/build/pkgbuilds/squash-git/src/squash/CMakeFiles/CMakeError.log".
nemequ commented 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…

Earnestly commented 7 years ago

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?

nemequ commented 7 years ago

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?

Earnestly commented 7 years ago

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

Cloudef commented 6 years ago

@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 commented 6 years ago

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

Cloudef commented 6 years ago

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?