Prepare for CMake 4.0 with package rebuild?

Dear fellow openSuse packagers! CMake prepares for a new major release 4.0. By default this will break every package that requires a minimum version of CMake <= 3.5. Can we create in OBS a mass rebuild with the latest release candidate of CMake 4.0 to see the fallout? I don't know how to do it and if I am allowed to do so. This would help to identify which package needs to be patched or even better, we can reach out to upstream with patches. Is it worth to open an issue to track the packages which needs to be addressed? By the way, SUSE libraries might be affected, too. For example libsolv has an according open merge request since last December, see https://github.com/openSUSE/libsolv/pull/575 Bye Christoph -- Most customers will not accept source code with compile errors in it. Dan Saks, CppCon 2016 (https://youtu.be/D7Sd8A6_fYU)

On 2025-03-08 17:03, Christoph G wrote:
CMake prepares for a new major release 4.0. By default this will break every package that requires a minimum version of CMake <= 3.5.
Can we create in OBS a mass rebuild with the latest release candidate of CMake 4.0 to see the fallout? I don't know how to do it
There are 1494 packages in Factory downstream of cmake, that's like 10% of the distribution. Worth looking at the fallout. There are multiple ways to do this. One straightforward one would be to submit CMake 4 and use the existing Factory staging mechanism and work on that until it is is green. This would cover Ring 1 I believe and would get cmake in fast, and trigger the package maintainers to look at their respective leaf packages soon through the regular build fail notification mechanisms. The other way, and that used by gcc, would be to have your own project with project linking. The "localdep" rebuild mechanism is appropriate I believe. https://en.opensuse.org/openSUSE:Build_Service_Concept_project_linking
and if I am allowed to do so.
With a linked project you may exceed a quota soon but that can be set up for you.
Is it worth to open an issue to track the packages which needs to be addressed?
Absolutely! Create a tracker bug with the basic information why it happens and what a packager would need to patch. Also add reproduction steps so those you contact can action immediately. Then create bugs "blocking" this parent bug with a link to it, assigning it to the respective package maintainers. Also it may help if you provided a cmake 4 package rc right now, so that anyone could see check right now if their packages or projects are impacted. Andreas

Hi, On 3/9/25 2:33 AM, Christoph G wrote:
I've created https://build.opensuse.org/project/show/home:simotek:cmake4 with all the packages that build require cmake and cmake 4.0.0-rc4 using the following as recommended by Dimstar. for pkg in $(osc whatdependson openSUSE:Factory cmake standard x86_64); do osc branch openSUSE:Factory $pkg home:simotek:cmake4 done Packages are still copying in but it seems like there are quite a few failures. Ive created a tracker bug https://bugzilla.opensuse.org/show_bug.cgi?id=1239788 for packages that need significant work (more then just setting a minimum version) its probably worth creating a bug and setting it to block the tracker bug. I have a couple of thing I need to finish up but I'll try and help you where I can so if we don't create bugs for each we might want to come up with a way that makes sure we aren't both working on the same packages. Thanks Simon -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Hello Simon, thank you for setting this up! It is so helpful and I already started to open issues and pull requests in the upstream projects. Further, Ben Boeckel from CMake asks [1]:
[1] https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-... Bye Christoph

Hi, On 3/24/25 6:20 PM, Christoph G wrote:
I've followed up in the discord discussion but i've created a second project [1] which adds `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` to the cmake macro. As of the time of writing there is still a pretty big rebuild happening but it seems to significantly reduce the number of failures. 1. https://build.opensuse.org/project/show/home:simotek:cmake4b -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 2025-03-08 17:03, Christoph G wrote:
CMake prepares for a new major release 4.0. By default this will break every package that requires a minimum version of CMake <= 3.5.
Can we create in OBS a mass rebuild with the latest release candidate of CMake 4.0 to see the fallout? I don't know how to do it
There are 1494 packages in Factory downstream of cmake, that's like 10% of the distribution. Worth looking at the fallout. There are multiple ways to do this. One straightforward one would be to submit CMake 4 and use the existing Factory staging mechanism and work on that until it is is green. This would cover Ring 1 I believe and would get cmake in fast, and trigger the package maintainers to look at their respective leaf packages soon through the regular build fail notification mechanisms. The other way, and that used by gcc, would be to have your own project with project linking. The "localdep" rebuild mechanism is appropriate I believe. https://en.opensuse.org/openSUSE:Build_Service_Concept_project_linking
and if I am allowed to do so.
With a linked project you may exceed a quota soon but that can be set up for you.
Is it worth to open an issue to track the packages which needs to be addressed?
Absolutely! Create a tracker bug with the basic information why it happens and what a packager would need to patch. Also add reproduction steps so those you contact can action immediately. Then create bugs "blocking" this parent bug with a link to it, assigning it to the respective package maintainers. Also it may help if you provided a cmake 4 package rc right now, so that anyone could see check right now if their packages or projects are impacted. Andreas

Hi, On 3/9/25 2:33 AM, Christoph G wrote:
I've created https://build.opensuse.org/project/show/home:simotek:cmake4 with all the packages that build require cmake and cmake 4.0.0-rc4 using the following as recommended by Dimstar. for pkg in $(osc whatdependson openSUSE:Factory cmake standard x86_64); do osc branch openSUSE:Factory $pkg home:simotek:cmake4 done Packages are still copying in but it seems like there are quite a few failures. Ive created a tracker bug https://bugzilla.opensuse.org/show_bug.cgi?id=1239788 for packages that need significant work (more then just setting a minimum version) its probably worth creating a bug and setting it to block the tracker bug. I have a couple of thing I need to finish up but I'll try and help you where I can so if we don't create bugs for each we might want to come up with a way that makes sure we aren't both working on the same packages. Thanks Simon -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Hello Simon, thank you for setting this up! It is so helpful and I already started to open issues and pull requests in the upstream projects. Further, Ben Boeckel from CMake asks [1]:
[1] https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-... Bye Christoph

Hi, On 3/24/25 6:20 PM, Christoph G wrote:
I've followed up in the discord discussion but i've created a second project [1] which adds `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` to the cmake macro. As of the time of writing there is still a pretty big rebuild happening but it seems to significantly reduce the number of failures. 1. https://build.opensuse.org/project/show/home:simotek:cmake4b -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (3)
-
Andreas Stieger
-
Christoph G
-
Simon Lees