You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working with a package that vendors QuaZip and also attempts to use a system QuaZip if found. It doesn't really work (the cmake config never finds the system quazip). I've patched it to find it, but now I'm having trouble actually doing the includes.
The patch that I have there allows me to build the package with a system QuaZip on Fedora, but when I attempt to apply that patch to the conda-forge package, it can't find quazip5/quazip.h. Looking into the build artifacts, it seems that there's a directory QuaZip-Qt5-1.4/quazip, so for that package, it should be quazip/quazip.h.
I'm not sure whether Fedora is doing something nonstandard, or the quazip-feedstock on conda-forge is doing something nonstandard, or if there are version differences I need to be looking at.
Is there a better way to set up the CMakeFiles to set sensible preprocessor definitions so that the various cases can be handled without patching for different build environments?
Note that all files inside quazip5 dir are symlinks to files in QuaZip-Qt5-1.4/quazip so quazip/quazip.h should be the correct usage after CMake properly resolves the dependencies and sets the paths.
Finding by QuaZip-Qt6 or by QuaZip-Qt5 name also seems correct and should be the same whether you have the fedora package installed or a local build+install. Fedora quazip-qt5-devel packages ships all the necessary .cmake files (in /usr/lib64/cmake/..) which makes it work.
Using a local build+install seems to be using the same nomenclature as on fedora, e.g.:
So as long as you put /usr/local in $PATH (or whatever install prefix you've set) the same name should work for find_package.
I tried find_package(QuaZip-Qt5 REQUIRED) on Fedora and it found it without any issues so I think I might need more details what exactly does not work. Simply looking at your patch, the fix is correct since the old package name was wrong.
edit: It might be that find_package by name "QuaZip" worked in the Qt4 era when there was a single supported version, but not all packages seem to be split between Qt versions.
Activity
cen1 commentedon Mar 7, 2025
Note that all files inside quazip5 dir are symlinks to files in QuaZip-Qt5-1.4/quazip so
quazip/quazip.hshould be the correct usage after CMake properly resolves the dependencies and sets the paths.Finding by
QuaZip-Qt6or byQuaZip-Qt5name also seems correct and should be the same whether you have the fedora package installed or a local build+install. Fedoraquazip-qt5-develpackages ships all the necessary .cmake files (in /usr/lib64/cmake/..) which makes it work.Using a local build+install seems to be using the same nomenclature as on fedora, e.g.:
So as long as you put
/usr/localin $PATH (or whatever install prefix you've set) the same name should work for find_package.I tried
find_package(QuaZip-Qt5 REQUIRED)on Fedora and it found it without any issues so I think I might need more details what exactly does not work. Simply looking at your patch, the fix is correct since the old package name was wrong.edit: It might be that find_package by name "QuaZip" worked in the Qt4 era when there was a single supported version, but not all packages seem to be split between Qt versions.
effigies commentedon Mar 7, 2025
Yeah, I started a new build directory and
quazip/worked, so maybe I just got into a weird state.Thanks for taking a look!