Skip to content
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

Open
Earnestly opened this issue May 22, 2017 · 7 comments
Open

cmake: zlib-ng check failure #228

Earnestly opened this issue May 22, 2017 · 7 comments

Comments

@Earnestly
Copy link

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
Copy link
Member

nemequ commented May 22, 2017

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
Copy link
Author

Earnestly commented May 22, 2017

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
Copy link
Member

nemequ commented May 22, 2017

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
Copy link
Author

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
Copy link
Contributor

Cloudef commented Sep 21, 2017

@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
Copy link
Member

nemequ commented Sep 21, 2017

@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
Copy link
Contributor

Cloudef commented Sep 21, 2017

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

generate_cmakein("${CMAKE_CURRENT_SOURCE_DIR}/zlib-ng/zconf.h.in" "${CMAKE_CURRENT_BINARY_DIR}/zconf.h.cmakein")
configure_file( ${CMAKE_CURRENT_BINARY_DIR}/zconf.h.cmakein
${CMAKE_CURRENT_BINARY_DIR}/zconf.h @ONLY)
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?

Cloudef added a commit to Cloudef/squash that referenced this issue Sep 29, 2017
Cloudef added a commit to Cloudef/squash that referenced this issue Sep 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants