Re: [Buildroot] [PATCH] package/cmake: bump version to 3.22.3

[Baruch Siach via buildroot <buildroot@buildroot.org>]

Hi Arnout,

On Wed, May 11 2022, Arnout Vandecappelle wrote:
> On 11/05/2022 12:06, Baruch Siach wrote:
>> On Wed, May 11 2022, Andrey Nechypurenko wrote:
>>>> On 10/05/2022 17:20, Andrey Nechypurenko wrote:
>>>>>>> I am just curious if the following patch will be accepted for the
>>>>>>> upcoming release?
>>>>>>
>>>>>> What about bumping it to 3.23.1?
>>>>>
>>>>> At the time I submitted the patch (29.03), v.3.22 was the latest one. It
>>>>> also fixes the bug I was facing. So it is good enough for me and definitely
>>>>> better than v.3.18 currently used by Buildroot. If you would like to submit
>>>>> another one for v. 3.23.1 it would be great.
>>>>
>>>>    Up to now, we've always kept the cmake version in sync with the value of
>>>> BR2_CMAKE_VERSION_MIN (defined in support/dependencies/check-host-cmake.mk and
>>>> updated every time there is a package that requires a specific newer version -
>>>> like swift would, as mentioned by Alsey.
>>>
>>> In addition to the Swift package mentioned by Alsey, there could be custom
>>> packages added by Buildroot users with external trees. This is what I am
>>> currently doing.
>>>
>>>>    What is the bug you were facing?
>>>
>>> Our custom package uses a feature which was buggy:
>>> https://gitlab.kitware.com/cmake/cmake/-/issues/18299 (it is also mentioned
>>> in the submitted patch). This bug was fixed in CMake 3.20.
>>>
>>>> Perhaps backporting its fix is appropriate?
>>>
>>> If the proposed patch with v.3.22 does not introduce any regression, then I
>>> personally do not see any reasons for backporting. 3.18 is two years old and
>>> it might be beneficial to switch to a newer one.
>> Backporting the cmake fix alone would not help hosts with cmake version
>> 3.18 installed. With current BR2_CMAKE_VERSION_MIN set to 3.18 Buildroot
>> will not build the fixed cmake host package, but rely instead on the
>> buggy host installed cmake.
>
>  So we have 3 options:
>
> - Keep the current situation, which creates problems for some external packages.
> - Update cmake but not BR2_CMAKE_VERSION_MIN, which is nice for keeping cmake
>   up to date but doesn't solve anything for people who run into the bug and
>  have CMake 3.18 or 3.19 installed.
> - Update both cmake and BR2_CMAKE_VERSION_MIN, which basically means that
>   everybody has to build host-cmake unless they have a really bleeding edge
>  distro.
>
>  There is a fourth, much more complicated option, which is to allow individual
>  packages to define the minimal cmake version. Then a package that actually
> runs into the problem can force BR2_CMAKE_VERSION_MIN. Of course we'd also
> need to change cmake.mk to use that config-dependendent cmake version. And
> we're in a bit of a tricky situation with the patch version - we'd prefer to
> set BR2_CMAKE_VERSION_MIN to e.g. 3.22, not 3.22.3, so people who have 3.22.1 
> installed on the host don't need to build host-cmake. And there's a problem
> with cmake.hash that needs to contain the hashes of many different versions.
>
>  So overall, nothing good :-(
>
>  With all of the above, I'd say we bump to 3.22.3 (this patch) and set
>  BR2_CMAKE_VERSION_MIN to 3.22. What do others think?

The bug that Andrey encountered is fixed in 3.20. So updating
BR2_CMAKE_VERSION_MIN to 3.20 should be enough, I believe.

Is there a reason to keep BR2_CMAKE_VERSION_MIN and cmake package
version in sync?

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot