Skip to content

Various CMake modernizations#40

Merged
Lecrapouille merged 27 commits intoLecrapouille:masterfrom
LecrisUT:cmake/modern
Jul 26, 2025
Merged

Various CMake modernizations#40
Lecrapouille merged 27 commits intoLecrapouille:masterfrom
LecrisUT:cmake/modern

Conversation

@LecrisUT
Copy link
Copy Markdown
Contributor

@LecrisUT LecrisUT commented Jul 18, 2025

A lot of points being addressed here:

  • Fixup the FetchContent support in line with the GTest usage (except additional USE_MODULE support)
  • Reorganize the project to follow some modern CMake practices
  • Had to bump minimum CMake to 3.13 in order to move the FetchContent parts to its own subdirectory
  • Scope-out the third-party variables (variables defined there don't propagate outwards, but the variables here propagate inwards)
  • Try to use consistent targets to support both find_package and FetchContent workflows

Closes #34

Lecrapouille and others added 26 commits June 17, 2025 02:05
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>
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, potatoes. Can you fix the Makefile part to account for this change? This change would be needed to support using system packages.

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ;(

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are not optional packages. They either comes from initially with make download-external-libs then I added git submodules for Red-Hat

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@LecrisUT
Copy link
Copy Markdown
Contributor Author

ZIPPER_BUILD_DEMOS should go away. Instead use a pattern like the one I am introducing here.

@Lecrapouille Lecrapouille force-pushed the master branch 2 times, most recently from 4de84a5 to 0351dc7 Compare July 26, 2025 07:33
@Lecrapouille Lecrapouille merged commit 7c5d3f4 into Lecrapouille:master Jul 26, 2025
0 of 4 checks passed
Lecrapouille pushed a commit that referenced this pull request Jul 26, 2025
@Lecrapouille
Copy link
Copy Markdown
Owner

@LecrisUT

  • I had to git push force the master branch to fix zipper versions in cmake to match my tags.
  • I moved your commits into the dev-modern-cmake branch

@LecrisUT
Copy link
Copy Markdown
Contributor Author

  • I had to git push force the master branch to fix zipper versions in cmake to match my tags.

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.

@Lecrapouille
Copy link
Copy Markdown
Owner

@LecrisUT yes for tags, but it's ok since people do not use this repo and mismatching versions with tags is more confusing.

I am confused by a lot of the commits being made.

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

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

Successfully merging this pull request may close these issues.

Improvements for Fedora packaging

3 participants