From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16050C8303C for ; Tue, 8 Jul 2025 13:13:14 +0000 (UTC) Subject: Re: [PATCH v5 0/7] cmake: Major version bump to 4.0.3 To: openembedded-core@lists.openembedded.org From: "Alper Ak" X-Originating-Location: Istanbul, TR (176.33.70.141) X-Originating-Platform: Linux Firefox 139 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Tue, 08 Jul 2025 06:13:11 -0700 References: In-Reply-To: Message-ID: <8340.1751980391085408362@lists.openembedded.org> Content-Type: multipart/alternative; boundary="8OaSm3wPvsyMHYXrwZcP" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 08 Jul 2025 13:13:14 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/220030 --8OaSm3wPvsyMHYXrwZcP Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=20 > 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 th= e >=20 > patches on. Are there some pointers we can follow from previous changes > of the same kind? >=20 >=20 > One idea I had to possibly speed the process up a bit: For starters, we > could > try building the "broken" recipes with >=20 >=20 > -DCMAKE_POLICY_VERSION_MINIMUM=3D3.5 >=20 >=20 > added to >=20 >=20 > EXTRA_OECMAKE >=20 >=20 > 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. >=20 I also considered the idea of temporarily using -DCMAKE_POLICY_VERSION_MINI= MUM=3D3.5 to quickly work around the CMake 4 issues across multiple recipes= . Then, I thought that directly upgrading recipes where the upstream versio= n could be updated was more sustainable solution. I believed this would res= olve many compatibility issues by relying on upstream fixes and encourage t= he community to use the latest versions. However, in cases where upgrading is not possible or incompatibilities pers= ist, adding a small patch (for example, allow-build-with-cmake-4.patch) tha= t 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-openembed= ded and Khem accepted them to master-next, but I still had the feeling that= maybe something better could be done. https://patchwork.yoctoproject.org/project/oe/list/?submitter=3D938 As I said, I have the feeling that it can be done better, so I will wait fo= r your answers before I do anything. --8OaSm3wPvsyMHYXrwZcP Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I'm happy to support here. I'd agree to what Alper said though: Some w= ay of
coordinating this effort seems to be required. Given the number = of affected
recipes it'd also be good to have a temporary branch / for= k to prepare the
patches on. Are there some pointers we can follow fro= m previous changes
of the same kind?

One idea I had to possibly speed the process up a bit: For starters, w= e could
try building the "broken" recipes with

-DCMAKE_POLICY_VERSION_MINIMUM=3D3.5

added to

EXTRA_OECMAKE

possibly via a temporary 'cmake-4-enforce-policy-compat' bbclass or so= me 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=3D3.5 to quickly work around the CMake 4 issues across multiple re= cipes. Then, I thought that directly upgrading recipes where the upstream v= ersion could be updated was more sustainable solution. I believed this woul= d resolve many compatibility issues by relying on upstream fixes and encour= age 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 sustain= able workaround.

On the other hand, applying similar patches across many recipes may re= quire manual cleanup in the future if the issue is eventually resolved upst= ream. Therefore, it is essential to keep track of synchronization with upst= ream over the long term.

Before our conversation I made a few things and sent them to meta-open= embedded 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 wa= it for your answers before I do anything.
--8OaSm3wPvsyMHYXrwZcP--