I'm happy to support here. I'd agree to what Alper said though: Some way of
coordinating this effort seems to be required. Given the number of affected
recipes it'd also be good to have a temporary branch / fork to prepare the
patches on. Are there some pointers we can follow from previous changes
of the same kind?
One idea I had to possibly speed the process up a bit: For starters, we could
try building the "broken" recipes with
-DCMAKE_POLICY_VERSION_MINIMUM=3.5
added to
EXTRA_OECMAKE
possibly via a temporary 'cmake-4-enforce-policy-compat' bbclass or some similar
mechanism. That would be faster then checking upstream for CMake-related patches
and adding them to the tree / recipes.
I also considered the idea of temporarily using -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to quickly work around the CMake 4 issues across multiple recipes. Then, I thought that directly upgrading recipes where the upstream version could be updated was more sustainable solution. I believed this would resolve many compatibility issues by relying on upstream fixes and encourage the community to use the latest versions.
However, in cases where upgrading is not possible or incompatibilities persist, adding a small patch (for example, allow-build-with-cmake-4.patch) that sets the minimum required CMake version to 3.5 can provide a sustainable workaround.
On the other hand, applying similar patches across many recipes may require manual cleanup in the future if the issue is eventually resolved upstream. Therefore, it is essential to keep track of synchronization with upstream over the long term.
Before our conversation I made a few things and sent them to meta-openembedded and Khem accepted them to master-next, but I still had the feeling that maybe something better could be done.
As I said, I have the feeling that it can be done better, so I will wait for your answers before I do anything.