Various CMake modernizations#40
Conversation
Simplified cleaning rules, fix installed folders for data and doc, allow creating RPM
* Add support for using packaged GTest Support is available only in CMake 3.24 and higer * Move enable_testing This needs to be present before any add_tests, otherwise the tests are not recorded properly
Useful for prototyping by pointing a dependent's `zipper_ROOT` to a build directory
| #include <minizip/ioapi_mem.h> | ||
| #include <minizip/minishared.h> | ||
| #include <minizip/unzip.h> | ||
| #include <minizip/zip.h> |
There was a problem hiding this comment.
Well, potatoes. Can you fix the Makefile part to account for this change? This change would be needed to support using system packages.
There was a problem hiding this comment.
This is not an issue for me with Makefile: it's just fixing a -I piece of cake. I find sad that the hard part is always coming from CMake. On the original project 99% of issues come from CMake that is why I used my Makefile system. I'm not even able to compile with your changes. The nightmare is coming back again ;(
There was a problem hiding this comment.
-- The following OPTIONAL packages have not been found:
- minizip
- zlib-ng
-- Configuring done (10.5s)
CMake Error: install(EXPORT "zipperTargets" ...) includes target "zipper" which requires target "zlib" that is not in any export set.
CMake Error in CMakeLists.txt:
export called with target "zipper" which requires target "minizip" that is
not in any export set.
CMake Error in CMakeLists.txt:
export called with target "zipper" which requires target "zlib" that is not
in any export set.
-- Generating done (0.0s)
CMake Generate step failed. Build files cannot be regenerated correctly.
There was a problem hiding this comment.
There are not optional packages. They either comes from initially with make download-external-libs then I added git submodules for Red-Hat
There was a problem hiding this comment.
-- Configuring done (10.5s)
CMake Error: install(EXPORT "zipperTargets" ...) includes target "zipper" which requires target "zlib" that is not in any export set.
This is a complex issue about static libraries requiring to have all dependencies installed. Iirc, that is an existing issue.
I can look into that afterwards, but for now, try building with -DZIPPER_SHARED_LIBS=ON
There was a problem hiding this comment.
@LecrisUT why not letting people doing git clone ... --recurse then either our CMakeLists includes directly the CMake inside the external/minizip/CMakeLists.txt our we compile the C++ files directly ? I can modify headers for you now
There was a problem hiding this comment.
@LecrisUT I have commited the includes. I'm not sure to switch "" to <> because, if I remember well the compiler will search for OS files first
There was a problem hiding this comment.
I'm not sure to switch "" to <> because, if I remember well the compiler will search for OS files first
Yes, but that is desired. You are signalling that this is a third-party library. The -I flags will make sure that the system dependency is picked up.
@LecrisUT why not letting people doing git clone ... --recurse then either our CMakeLists includes directly the CMake inside the external/minizip/CMakeLists.txt our we compile the C++ files directly ? I can modify headers for you now
The reason for this change is to make way to allow building against a system minizip which exports it as #include <minizip/*>. This will make it easier to pull in minizip-ng-compat-devel make it compatible with that, and move the bundled minizip to the upstream version.
|
|
4de84a5 to
0351dc7
Compare
|
Please refrain from doing that if this ends up in downstream packaging. Changing the checksum of a tag will break almost all downstream packages. Instead you can remove a release and get a newer tag that fixes the issue. I am confused by a lot of the commits being made. To be blunt I suspect that they were done through vibe-coding. If you have people willing to help you with the project and willing to share their expertise, please allow them provide feedback before accepting the AI input at face value. |
|
@LecrisUT yes for tags, but it's ok since people do not use this repo and mismatching versions with tags is more confusing.
Concerning which parts ? I used IA for CMake because I do not know how the syntax. I used once for fixing big slow down issue and for refactoring unit tests when I modified the API. I just made a branch of your commits temporarily to be merged into the main branch later when I'll have time to investigate on CMake |
A lot of points being addressed here:
USE_MODULEsupport)find_packageandFetchContentworkflowsCloses #34