Message ID | 20220329145904.63900-1-andreynech@gmail.com |
---|---|
State | Changes Requested |
Headers | show |
Series | package/cmake: bump version to 3.22.3 | expand |
This newer version of cmake is also needed to cross compile Appleās Swift programming language, so it would be great if this got merged. > On Mar 29, 2022, at 7:59 AM, Andrey Nechypurenko <andreynech@gmail.com> wrote: > > Version 3.20 is the first one where the following issue is fixed: > https://gitlab.kitware.com/cmake/cmake/-/issues/18299 > Was affected by this bug and decide to bump the version to the > latest stable > --- > package/cmake/cmake.hash | 4 ++-- > package/cmake/cmake.mk | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash > index da514a6d6b..1749db8c27 100644 > --- a/package/cmake/cmake.hash > +++ b/package/cmake/cmake.hash > @@ -1,5 +1,5 @@ > -# From https://cmake.org/files/v3.18/cmake-3.18.6-SHA-256.txt > -sha256 124f571ab70332da97a173cb794dfa09a5b20ccbb80a08e56570a500f47b6600 cmake-3.18.6.tar.gz > +# From https://cmake.org/files/v3.22/cmake-3.22.3-SHA-256.txt > +sha256 9f8469166f94553b6978a16ee29227ec49a2eb5ceb608275dec40d8ae0d1b5a0 cmake-3.22.3.tar.gz > > # Locally calculated > sha256 131b9ff756b64a25b7461c3c1382e70b16c70a5b4833a1577897fa3ea6d88f8d Copyright.txt > diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk > index 4177b119ab..053658fad6 100644 > --- a/package/cmake/cmake.mk > +++ b/package/cmake/cmake.mk > @@ -4,8 +4,8 @@ > # > ################################################################################ > > -CMAKE_VERSION_MAJOR = 3.18 > -CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).6 > +CMAKE_VERSION_MAJOR = 3.22 > +CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3 > CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR) > CMAKE_LICENSE = BSD-3-Clause > CMAKE_LICENSE_FILES = Copyright.txt > -- > 2.32.0 > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
Hi Folks, I am just curious if the following patch will be accepted for the upcoming release? Thank you, Andrey. On Tue, 29 Mar 2022 at 16:59, Andrey Nechypurenko <andreynech@gmail.com> wrote: > > Version 3.20 is the first one where the following issue is fixed: > https://gitlab.kitware.com/cmake/cmake/-/issues/18299 > Was affected by this bug and decide to bump the version to the > latest stable > --- > package/cmake/cmake.hash | 4 ++-- > package/cmake/cmake.mk | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash > index da514a6d6b..1749db8c27 100644 > --- a/package/cmake/cmake.hash > +++ b/package/cmake/cmake.hash > @@ -1,5 +1,5 @@ > -# From https://cmake.org/files/v3.18/cmake-3.18.6-SHA-256.txt > -sha256 124f571ab70332da97a173cb794dfa09a5b20ccbb80a08e56570a500f47b6600 cmake-3.18.6.tar.gz > +# From https://cmake.org/files/v3.22/cmake-3.22.3-SHA-256.txt > +sha256 9f8469166f94553b6978a16ee29227ec49a2eb5ceb608275dec40d8ae0d1b5a0 cmake-3.22.3.tar.gz > > # Locally calculated > sha256 131b9ff756b64a25b7461c3c1382e70b16c70a5b4833a1577897fa3ea6d88f8d Copyright.txt > diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk > index 4177b119ab..053658fad6 100644 > --- a/package/cmake/cmake.mk > +++ b/package/cmake/cmake.mk > @@ -4,8 +4,8 @@ > # > ################################################################################ > > -CMAKE_VERSION_MAJOR = 3.18 > -CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).6 > +CMAKE_VERSION_MAJOR = 3.22 > +CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3 > CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR) > CMAKE_LICENSE = BSD-3-Clause > CMAKE_LICENSE_FILES = Copyright.txt > -- > 2.32.0 >
Hi Andrey, On Tue, May 10, 2022 at 5:02 PM Andrey Nechypurenko <andreynech@gmail.com> wrote: > > Hi Folks, > > I am just curious if the following patch will be accepted for the > upcoming release? What about bumping it to 3.23.1? Regards, Yegor > Thank you, > Andrey. > > On Tue, 29 Mar 2022 at 16:59, Andrey Nechypurenko <andreynech@gmail.com> wrote: > > > > Version 3.20 is the first one where the following issue is fixed: > > https://gitlab.kitware.com/cmake/cmake/-/issues/18299 > > Was affected by this bug and decide to bump the version to the > > latest stable > > --- > > package/cmake/cmake.hash | 4 ++-- > > package/cmake/cmake.mk | 4 ++-- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash > > index da514a6d6b..1749db8c27 100644 > > --- a/package/cmake/cmake.hash > > +++ b/package/cmake/cmake.hash > > @@ -1,5 +1,5 @@ > > -# From https://cmake.org/files/v3.18/cmake-3.18.6-SHA-256.txt > > -sha256 124f571ab70332da97a173cb794dfa09a5b20ccbb80a08e56570a500f47b6600 cmake-3.18.6.tar.gz > > +# From https://cmake.org/files/v3.22/cmake-3.22.3-SHA-256.txt > > +sha256 9f8469166f94553b6978a16ee29227ec49a2eb5ceb608275dec40d8ae0d1b5a0 cmake-3.22.3.tar.gz > > > > # Locally calculated > > sha256 131b9ff756b64a25b7461c3c1382e70b16c70a5b4833a1577897fa3ea6d88f8d Copyright.txt > > diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk > > index 4177b119ab..053658fad6 100644 > > --- a/package/cmake/cmake.mk > > +++ b/package/cmake/cmake.mk > > @@ -4,8 +4,8 @@ > > # > > ################################################################################ > > > > -CMAKE_VERSION_MAJOR = 3.18 > > -CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).6 > > +CMAKE_VERSION_MAJOR = 3.22 > > +CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3 > > CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR) > > CMAKE_LICENSE = BSD-3-Clause > > CMAKE_LICENSE_FILES = Copyright.txt > > -- > > 2.32.0 > > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
Hi Yegor, > > 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. Regards, Andrey.
On 10/05/2022 17:20, Andrey Nechypurenko wrote: > Hi Yegor, > >>> 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. However, I'm not altogether sure why we do that. Probably so we can detect the need for newer cmake in the autobuilders. But maybe we should tackle that in a different way. What is the bug you were facing? Perhaps backporting its fix is appropriate? Regards, Arnout
Hi Arnout, > On 10/05/2022 17:20, Andrey Nechypurenko wrote: > > Hi Yegor, > > > >>> 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. Regards, Andrey.
Hi Andrey, 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. baruch
On 11/05/2022 12:06, Baruch Siach wrote: > Hi Andrey, > > 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? Regards, Arnout
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
Hi Arnout, > 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? I agree with this proposal. I also like the suggestion from Baruch to set BR2_CMAKE_VERSION_MIN to 3.20 (not 3.22) Regards, Andrey.
On 11/05/2022 19:58, Baruch Siach wrote: > 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? I think the only reason not to keep them in sync is to increase the exposure of possible defective cmake versions in the autobuilders. If we set BR2_CMAKE_VERSION_MIN to 3.20 and CMAKE_VERSION to 3.22.3, then if there is some issue with either 3.20 or 3.21, it will not be caught by the autobuilders, unless one of them happens to have one of the defective versions installed. But I see now that this didn't use to be the case. Fabrice started to align them in Nov 2019, but before that the host-cmake version was indeed ahead of BR2_CMAKE_VERSION_MIN. So I guess this patch is actually good to go. Updating BR2_CMAKE_VERSION_MIN can be done in a separate patch (but isn't strictly required). Regards, Arnout
Hi Arnout, > So I guess this patch is actually good to go. Updating BR2_CMAKE_VERSION_MIN > can be done in a separate patch (but isn't strictly required). Is anybody going to actually integrate/apply the patch so that changes will be available in the next release? Thanks, Andrey.
ping.... :-) On Thu, 19 May 2022 at 18:18, Andrey Nechypurenko <andreynech@gmail.com> wrote: > > Hi Arnout, > > > So I guess this patch is actually good to go. Updating BR2_CMAKE_VERSION_MIN > > can be done in a separate patch (but isn't strictly required). > > Is anybody going to actually integrate/apply the patch so that changes will > be available in the next release? > > Thanks, > Andrey.
Andrey, All, On 2022-03-29 16:59 +0200, Andrey Nechypurenko spake thusly: > Version 3.20 is the first one where the following issue is fixed: > https://gitlab.kitware.com/cmake/cmake/-/issues/18299 > Was affected by this bug and decide to bump the version to the > latest stable I was about to apply this, but you did not sign-off your change, so I can't apply it. Please, resent with your sign-off. Regards, Yann E. MORIN. > --- > package/cmake/cmake.hash | 4 ++-- > package/cmake/cmake.mk | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash > index da514a6d6b..1749db8c27 100644 > --- a/package/cmake/cmake.hash > +++ b/package/cmake/cmake.hash > @@ -1,5 +1,5 @@ > -# From https://cmake.org/files/v3.18/cmake-3.18.6-SHA-256.txt > -sha256 124f571ab70332da97a173cb794dfa09a5b20ccbb80a08e56570a500f47b6600 cmake-3.18.6.tar.gz > +# From https://cmake.org/files/v3.22/cmake-3.22.3-SHA-256.txt > +sha256 9f8469166f94553b6978a16ee29227ec49a2eb5ceb608275dec40d8ae0d1b5a0 cmake-3.22.3.tar.gz > > # Locally calculated > sha256 131b9ff756b64a25b7461c3c1382e70b16c70a5b4833a1577897fa3ea6d88f8d Copyright.txt > diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk > index 4177b119ab..053658fad6 100644 > --- a/package/cmake/cmake.mk > +++ b/package/cmake/cmake.mk > @@ -4,8 +4,8 @@ > # > ################################################################################ > > -CMAKE_VERSION_MAJOR = 3.18 > -CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).6 > +CMAKE_VERSION_MAJOR = 3.22 > +CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3 > CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR) > CMAKE_LICENSE = BSD-3-Clause > CMAKE_LICENSE_FILES = Copyright.txt > -- > 2.32.0 > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
Version 3.20 is the first one where the following issue is fixed:
https://gitlab.kitware.com/cmake/cmake/-/issues/18299
Was affected by this bug and decide to bump the version to the
latest stable
Signed-off-by: Andrey Nechypurenko <andreynech@gmail.com>
---
package/cmake/cmake.hash | 4 ++--
package/cmake/cmake.mk | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash
index da514a6d6b..1749db8c27 100644
--- a/package/cmake/cmake.hash
+++ b/package/cmake/cmake.hash
@@ -1,5 +1,5 @@
-# From https://cmake.org/files/v3.18/cmake-3.18.6-SHA-256.txt
-sha256 124f571ab70332da97a173cb794dfa09a5b20ccbb80a08e56570a500f47b6600
cmake-3.18.6.tar.gz
+# From https://cmake.org/files/v3.22/cmake-3.22.3-SHA-256.txt
+sha256 9f8469166f94553b6978a16ee29227ec49a2eb5ceb608275dec40d8ae0d1b5a0
cmake-3.22.3.tar.gz
# Locally calculated
sha256 131b9ff756b64a25b7461c3c1382e70b16c70a5b4833a1577897fa3ea6d88f8d
Copyright.txt
diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk
index 4177b119ab..053658fad6 100644
--- a/package/cmake/cmake.mk
+++ b/package/cmake/cmake.mk
@@ -4,8 +4,8 @@
#
################################################################################
-CMAKE_VERSION_MAJOR = 3.18
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).6
+CMAKE_VERSION_MAJOR = 3.22
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3
CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
CMAKE_LICENSE = BSD-3-Clause
CMAKE_LICENSE_FILES = Copyright.txt
--
2.32.0
It looks like gmail adds line breaks. Will resend it using git in a few minutes. Sorry for the inconvenience. On Mon, 30 May 2022 at 14:38, Andrey Nechypurenko <andreynech@gmail.com> wrote: > > Version 3.20 is the first one where the following issue is fixed: > https://gitlab.kitware.com/cmake/cmake/-/issues/18299 > Was affected by this bug and decide to bump the version to the > latest stable > > Signed-off-by: Andrey Nechypurenko <andreynech@gmail.com> > --- > package/cmake/cmake.hash | 4 ++-- > package/cmake/cmake.mk | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash > index da514a6d6b..1749db8c27 100644 > --- a/package/cmake/cmake.hash > +++ b/package/cmake/cmake.hash > @@ -1,5 +1,5 @@ > -# From https://cmake.org/files/v3.18/cmake-3.18.6-SHA-256.txt > -sha256 124f571ab70332da97a173cb794dfa09a5b20ccbb80a08e56570a500f47b6600 > cmake-3.18.6.tar.gz > +# From https://cmake.org/files/v3.22/cmake-3.22.3-SHA-256.txt > +sha256 9f8469166f94553b6978a16ee29227ec49a2eb5ceb608275dec40d8ae0d1b5a0 > cmake-3.22.3.tar.gz > > # Locally calculated > sha256 131b9ff756b64a25b7461c3c1382e70b16c70a5b4833a1577897fa3ea6d88f8d > Copyright.txt > diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk > index 4177b119ab..053658fad6 100644 > --- a/package/cmake/cmake.mk > +++ b/package/cmake/cmake.mk > @@ -4,8 +4,8 @@ > # > ################################################################################ > > -CMAKE_VERSION_MAJOR = 3.18 > -CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).6 > +CMAKE_VERSION_MAJOR = 3.22 > +CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3 > CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR) > CMAKE_LICENSE = BSD-3-Clause > CMAKE_LICENSE_FILES = Copyright.txt > -- > 2.32.0
diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash index da514a6d6b..1749db8c27 100644 --- a/package/cmake/cmake.hash +++ b/package/cmake/cmake.hash @@ -1,5 +1,5 @@ -# From https://cmake.org/files/v3.18/cmake-3.18.6-SHA-256.txt -sha256 124f571ab70332da97a173cb794dfa09a5b20ccbb80a08e56570a500f47b6600 cmake-3.18.6.tar.gz +# From https://cmake.org/files/v3.22/cmake-3.22.3-SHA-256.txt +sha256 9f8469166f94553b6978a16ee29227ec49a2eb5ceb608275dec40d8ae0d1b5a0 cmake-3.22.3.tar.gz # Locally calculated sha256 131b9ff756b64a25b7461c3c1382e70b16c70a5b4833a1577897fa3ea6d88f8d Copyright.txt diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk index 4177b119ab..053658fad6 100644 --- a/package/cmake/cmake.mk +++ b/package/cmake/cmake.mk @@ -4,8 +4,8 @@ # ################################################################################ -CMAKE_VERSION_MAJOR = 3.18 -CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).6 +CMAKE_VERSION_MAJOR = 3.22 +CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).3 CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR) CMAKE_LICENSE = BSD-3-Clause CMAKE_LICENSE_FILES = Copyright.txt