Building with make leaves out CMake files

[MarcusCalhoun-Lopez]

Is your feature request related to a problem? Please describe. The MacPorts project builds zstd using make. There are various reasons, not the least of which is that, according to the README.md file, "make is the officially maintained build system of this project." However, the CMake files of zstd are installed if and only if zstd is built with CMake (not make). This is a problem since the CMake files of minizip-ng require the CMake files of zstd to be installed.

Describe the solution you'd like Is there any way to install the CMake files of zstd using only make?

Describe alternatives you've considered There is pull request that attempts to install zstd (via make) and its CMake files (via cmake) separately. However, this is a less than ideal solution.

Additional context

[nekopsykose]

This is a problem since the CMake files of minizip-ng require the CMake files of zstd to be installed.

are you sure? minizip-ng itself uses pkg-config to find zstd for itself at build time. if the final cmake files only work with zstd cmake files, then that should be fixed in minizip-ng.

[MarcusCalhoun-Lopez]

Sorry if I was not clear. minizip-ng builds just fine. However, the CMake files that minizip-ng installs assumes the CMake files of zstd exist.

Just as an example: During its configure phase, OpenColorIO looks for minizip-ng. find_package(minizip-ng ... uses the file minizip-ng-config.cmake installed by minizip-ng. However, within the file minizip-ng-config.cmake, there is a line find_dependency(zstd REQUIRED). zstdConfig.cmake is installed by zstd if and only if zstd is built with CMake (not make).

Just so I am clear, it is a bug in minizip-ng to assume zstdConfig.cmake exists?

[nekopsykose]

Just so I am clear, it is a bug in minizip-ng to assume zstdConfig.cmake exists?

i would say yes- while you can get a zstdConfig.cmake by using the contributed cmake build system in this repository, only the Makefile one is supported, and since it does not emit any cmake files then they should not be assumed to exist by anything else either.

of course, this is exactly what you are requesting to change, so idk :) i don't know of a way to write cmake config files by hand in a way that works reliably instead of having cmake generate it itself (which has a lot of bootstrapping issues in this case..)

[bnavigator]

Shipping zstd cmake files creates problems with packages not expecting them: https://bugzilla.opensuse.org/show_bug.cgi?id=1211566

[pinkflames]

I just got hit by this same issue. As @bnavigator is pointing out, some software simply expects the CMake based dependency detection, because zstd often comes with a cmake file and no one would expect that to be an optional or randomly present file. If building zstd with make causes such deficiencies, then the resulting build is essentially broken and that's a zstd bug.

Perhaps the issue is that CMake's find_dependency() is the one that mandates use of cmake files but I'm not familiar with CMake and a quick googling does not clearly explain if find_dependency() is exclusive to the CMake ecosystem.

Whatever the case, the way things are is not acceptable and either zstd or CMake needs to be fixed to not break, when zstd is built with make and not cmake. Or the make build system could be officially deprecated and preferably removed to make it clear to distros that they are not supposed to use it.

[maxnoe]

:+1: here: the installed package shouldn't depend on the build system