[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Mario Lang]

Signed-off-by: Mario Lang <mlang@blind.guru>
---
 package/cmake/cmake.hash | 5 +++--
 package/cmake/cmake.mk   | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/package/cmake/cmake.hash b/package/cmake/cmake.hash
index f138ac79a1..b095d722c6 100644
--- a/package/cmake/cmake.hash
+++ b/package/cmake/cmake.hash
@@ -1,2 +1,3 @@
-# From http://www.cmake.org/files/v3.8/cmake-3.8.2-SHA-256.txt
-sha256 da3072794eb4c09f2d782fcee043847b99bb4cf8d4573978d9b2024214d6e92d  cmake-3.8.2.tar.gz
+# From http://www.cmake.org/files/v3.10/cmake-3.10.0-SHA-256.txt
+sha256 b3345c17609ea0f039960ef470aa099de9942135990930a57c14575aae884987  cmake-3.10.0.tar.gz
+sha256 ccf2c6d4468919c8c26a764b9ed8fde349f0d298335524568b346b9bdcf56e1f  Copyright.txt
diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk
index a00691a128..601bb43b6b 100644
--- a/package/cmake/cmake.mk
+++ b/package/cmake/cmake.mk
@@ -4,8 +4,8 @@
 #
 ################################################################################
 
-CMAKE_VERSION_MAJOR = 3.8
-CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).2
+CMAKE_VERSION_MAJOR = 3.10
+CMAKE_VERSION = $(CMAKE_VERSION_MAJOR).0
 CMAKE_SITE = https://cmake.org/files/v$(CMAKE_VERSION_MAJOR)
 CMAKE_LICENSE = BSD-3-Clause
 CMAKE_LICENSE_FILES = Copyright.txt
-- 
2.15.0

[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Thomas Petazzoni]

Hello,

On Mon, 11 Dec 2017 00:33:49 +0100, Mario Lang wrote:
> Signed-off-by: Mario Lang <mlang@blind.guru>
> ---
>  package/cmake/cmake.hash | 5 +++--
>  package/cmake/cmake.mk   | 4 ++--
>  2 files changed, 5 insertions(+), 4 deletions(-)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Thomas Petazzoni]

Hello,

On Tue, 12 Dec 2017 07:07:36 +0100, Thomas Petazzoni wrote:

> On Mon, 11 Dec 2017 00:33:49 +0100, Mario Lang wrote:
> > Signed-off-by: Mario Lang <mlang@blind.guru>
> > ---
> >  package/cmake/cmake.hash | 5 +++--
> >  package/cmake/cmake.mk   | 4 ++--
> >  2 files changed, 5 insertions(+), 4 deletions(-)  
> 
> Applied to master, thanks.

And I had to revert it, because it was causing gazillions of build
failures of host-cmake:

  http://autobuild.buildroot.net/?reason=host-cmake-3.10.0

Indeed, CMake is now using the emplace_hint method, which is only
available in C++11, so it probably requires gcc 4.7 or gcc 4.8, and the
CMake package doesn't account for this dependency.

The gotcha is that it's not going to be easy to solve. Indeed, our
current logic is:

 1. If there is a suitable CMake available on the system, we use it

 2. If there's no suitable CMake available on the system, we build our
    own.

In situation (1), we are still good, no problem. But in situation (2),
what do we do if we cannot built CMake at all because the host compiler
is too old ? The only option would be to prevent the user from enabling
any package that will need host-cmake. This means all cmake-based
packages, and all their reverse dependencies.

Really, that's quite a bit of work. Perhaps this should instead be
taken as a bug/regression to CMake, and see if they are willing to use
a different approach when emplace_hint is not available ?

Seems like emplace_hint() is adding a new element to a container, with
a hint as to where it should be added. So I believe this is an
optimization, so perhaps if emplace_hint() is not available, CMake
could fallback on just inserting the element in the container.

Mario, are you interested in looking into this ?

Thanks a lot,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Mario Lang]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

> And I had to revert it, because it was causing gazillions of build
> failures of host-cmake:
>
>   http://autobuild.buildroot.net/?reason=host-cmake-3.10.0
>
> Indeed, CMake is now using the emplace_hint method, which is only
> available in C++11, so it probably requires gcc 4.7 or gcc 4.8, and the
> CMake package doesn't account for this dependency.
>
> The gotcha is that it's not going to be easy to solve. Indeed, our
> current logic is:
>
>  1. If there is a suitable CMake available on the system, we use it
>
>  2. If there's no suitable CMake available on the system, we build our
>     own.
>
> In situation (1), we are still good, no problem. But in situation (2),
> what do we do if we cannot built CMake at all because the host compiler
> is too old ? The only option would be to prevent the user from enabling
> any package that will need host-cmake. This means all cmake-based
> packages, and all their reverse dependencies.
>
> Really, that's quite a bit of work. Perhaps this should instead be
> taken as a bug/regression to CMake, and see if they are willing to use
> a different approach when emplace_hint is not available ?

To move to C++11 was apparently intentional, and not an oversight.
Quoting the release notes of 3.10:

"
Deprecated and Removed Features?

     * Support for building CMake itself with C++98 compilers was
       dropped. CMake is now implemented using C++11.
"

6 years after the standard was released, some projects are
starting to move to it.  LLVM comes to mind, which you also can't build
without C++11 anymore.

> Seems like emplace_hint() is adding a new element to a container, with
> a hint as to where it should be added. So I believe this is an
> optimization, so perhaps if emplace_hint() is not available, CMake
> could fallback on just inserting the element in the container.

This particular case might be patchable, but the explicit notice quoted
above makes me think it might not be worthwhile to try and write a
backporting patch.

> Mario, are you interested in looking into this ?

Yes, actually, I am.  However, I am a bit to rooky to Buildroot to
understand enough about how you handle backwards compatibility in
general.  My gut feeling as a C++11 fan would be to just accept the fact
that C++11 is going to be required by projects in the future.  However,
I gather Buildroot has official minimal compiler requirements which are
likely dictated by toolchains provided by other vendors?

In the meantime, since I found this notice in 3.10, we might consider
moving cmake at least to 3.9?

-- 
CYa,
  ?????

[Buildroot] FW: [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Kees van Unen]

________________________________________
Van: buildrootNamensMario Lang
Verzonden: zaterdag 16 december 2017 11:52:12 (UTC+01:00) Amsterdam, Berlijn, Bern, Rome, Stockholm, Wenen
Aan: Thomas Petazzoni
CC: buildroot at buildroot.org
Onderwerp: Re: [Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

> And I had to revert it, because it was causing gazillions of build
> failures of host-cmake:
>
>   http://autobuild.buildroot.net/?reason=host-cmake-3.10.0
>
> Indeed, CMake is now using the emplace_hint method, which is only
> available in C++11, so it probably requires gcc 4.7 or gcc 4.8, and the
> CMake package doesn't account for this dependency.
>
> The gotcha is that it's not going to be easy to solve. Indeed, our
> current logic is:
>
>  1. If there is a suitable CMake available on the system, we use it
>
>  2. If there's no suitable CMake available on the system, we build our
>     own.
>
> In situation (1), we are still good, no problem. But in situation (2),
> what do we do if we cannot built CMake at all because the host compiler
> is too old ? The only option would be to prevent the user from enabling
> any package that will need host-cmake. This means all cmake-based
> packages, and all their reverse dependencies.
>
> Really, that's quite a bit of work. Perhaps this should instead be
> taken as a bug/regression to CMake, and see if they are willing to use
> a different approach when emplace_hint is not available ?

To move to C++11 was apparently intentional, and not an oversight.
Quoting the release notes of 3.10:

"
Deprecated and Removed Features?

     * Support for building CMake itself with C++98 compilers was
       dropped. CMake is now implemented using C++11.
"

6 years after the standard was released, some projects are
starting to move to it.  LLVM comes to mind, which you also can't build
without C++11 anymore.

> Seems like emplace_hint() is adding a new element to a container, with
> a hint as to where it should be added. So I believe this is an
> optimization, so perhaps if emplace_hint() is not available, CMake
> could fallback on just inserting the element in the container.

This particular case might be patchable, but the explicit notice quoted
above makes me think it might not be worthwhile to try and write a
backporting patch.

> Mario, are you interested in looking into this ?

Yes, actually, I am.  However, I am a bit to rooky to Buildroot to
understand enough about how you handle backwards compatibility in
general.  My gut feeling as a C++11 fan would be to just accept the fact
that C++11 is going to be required by projects in the future.  However,
I gather Buildroot has official minimal compiler requirements which are
likely dictated by toolchains provided by other vendors?

In the meantime, since I found this notice in 3.10, we might consider
moving cmake at least to 3.9?

--
CYa,
  ?????
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Thomas Petazzoni]

Hello,

On Sat, 16 Dec 2017 11:52:12 +0100, Mario Lang wrote:

> To move to C++11 was apparently intentional, and not an oversight.
> Quoting the release notes of 3.10:
> 
> "
> Deprecated and Removed Features?
> 
>      * Support for building CMake itself with C++98 compilers was
>        dropped. CMake is now implemented using C++11.
> "
> 
> 6 years after the standard was released, some projects are
> starting to move to it.  LLVM comes to mind, which you also can't build
> without C++11 anymore.
> 
> > Seems like emplace_hint() is adding a new element to a container, with
> > a hint as to where it should be added. So I believe this is an
> > optimization, so perhaps if emplace_hint() is not available, CMake
> > could fallback on just inserting the element in the container.  
> 
> This particular case might be patchable, but the explicit notice quoted
> above makes me think it might not be worthwhile to try and write a
> backporting patch.

OK, thanks for the investigation.

> > Mario, are you interested in looking into this ?  
> 
> Yes, actually, I am.  However, I am a bit to rooky to Buildroot to
> understand enough about how you handle backwards compatibility in
> general.  My gut feeling as a C++11 fan would be to just accept the fact
> that C++11 is going to be required by projects in the future.  However,
> I gather Buildroot has official minimal compiler requirements which are
> likely dictated by toolchains provided by other vendors?

We can already have dependencies on gcc versions, both for the host
compiler and the target compiler, see BR2_HOST_GCC_AT_LEAST_ for the
host compiler version dependencies and BR2_TOOLCHAIN_GCC_AT_LEAST_ for
the target compiler version dependencies.

However, the problem is that we would have to propagate this dependency
to all packages using cmake, and all their reverse dependencies. It's
definitely not impossible, but it's going to be quite a few packages.

Also, it is complicated by the fact that we should not add this
dependency if cmake is already installed system-wide, as we only build
host-cmake if we can't find a suitable cmake version.

Basically, it all boils down to have a Config.in option that tells us
whether we need to build host-cmake or not, and whether we *can* build
it, and add this dependency to all cmake packages and their reverse
dependencies.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Yann E. MORIN]

Thomas, Mario, All,

On 2017-12-16 13:34 +0100, Thomas Petazzoni spake thusly:
> On Sat, 16 Dec 2017 11:52:12 +0100, Mario Lang wrote:
> > To move to C++11 was apparently intentional, and not an oversight.
[--SNIP--]
> > Yes, actually, I am.  However, I am a bit to rooky to Buildroot to
> > understand enough about how you handle backwards compatibility in
> > general.  My gut feeling as a C++11 fan would be to just accept the fact
> > that C++11 is going to be required by projects in the future.  However,
> > I gather Buildroot has official minimal compiler requirements which are
> > likely dictated by toolchains provided by other vendors?
> 
> We can already have dependencies on gcc versions, both for the host
> compiler and the target compiler, see BR2_HOST_GCC_AT_LEAST_ for the
> host compiler version dependencies and BR2_TOOLCHAIN_GCC_AT_LEAST_ for
> the target compiler version dependencies.
> 
> However, the problem is that we would have to propagate this dependency
> to all packages using cmake, and all their reverse dependencies. It's
> definitely not impossible, but it's going to be quite a few packages.
> 
> Also, it is complicated by the fact that we should not add this
> dependency if cmake is already installed system-wide, as we only build
> host-cmake if we can't find a suitable cmake version.
> 
> Basically, it all boils down to have a Config.in option that tells us
> whether we need to build host-cmake or not, and whether we *can* build
> it, and add this dependency to all cmake packages and their reverse
> dependencies.

Alternatively, we could also consider bumping our own requirements now,
requiring a newer base system.

Yes, that would mean leaving out in the cold people stuck on *very
ancient* enterprise-class distros (which IMHO would be a bit sad). But I
would prefer that rather than springling a dependency in all packages...

Unless we also build our own host toolchain? ;-] Well, probably a host
C/C++ compiler would be enough to build is needed, until we also need to
build binutils and a C library and whatnot... This should be avoided if
at all possible.

emplace_hint() has been added in gcc-4.7 (listed as a defect in 4.6).
However, some of the build failures are on a machine with gcc-4.7.2;

    http://autobuild.buildroot.org/results/ae8/ae88e2addefab8c7ccefa853c87313034ea241bc/build-end.log
    [--SNIP--]
    -- The C compiler identification is GNU 4.7.2
    -- The CXX compiler identification is GNU 4.7.2
    [--SNIP--]
    cmGlobalNinjaGenerator.cxx:1077:40: error: 'class std::map<const
    cmGeneratorTarget*, std::set<std::basic_string<char> > >' has no member
    named 'emplace_hint'

But all the failures occur on gcc-20...

I looke at my autobuilder, and it uses gcc-4.8.2, and cmake builds fine
with that...

gcc-4.8 was released in March 2013, which will be almost 5 years ago
when we tag LTS 2018.02. So maybe we can keep using cmake-3.9 up until
2018.02, then update our requirements to require a host gcc >= 4.8m
which will allow us to bump cmake to 3.10.

I agree that, with time passing, more and more packages will require
C++11, so it will make sense to require proper C++11 support for the
host compiler.

Regards,
Yann E. MORIN.

> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 > Alternatively, we could also consider bumping our own requirements now,
 > requiring a newer base system.

 > Yes, that would mean leaving out in the cold people stuck on *very
 > ancient* enterprise-class distros (which IMHO would be a bit sad). But I
 > would prefer that rather than springling a dependency in all packages...

 > Unless we also build our own host toolchain? ;-] Well, probably a host
 > C/C++ compiler would be enough to build is needed, until we also need to
 > build binutils and a C library and whatnot... This should be avoided if
 > at all possible.

Argh, let's not go there! ;)

 > emplace_hint() has been added in gcc-4.7 (listed as a defect in 4.6).
 > However, some of the build failures are on a machine with gcc-4.7.2;

 >     http://autobuild.buildroot.org/results/ae8/ae88e2addefab8c7ccefa853c87313034ea241bc/build-end.log
 >     [--SNIP--]
 >     -- The C compiler identification is GNU 4.7.2
 >     -- The CXX compiler identification is GNU 4.7.2
 >     [--SNIP--]
 >     cmGlobalNinjaGenerator.cxx:1077:40: error: 'class std::map<const
 >     cmGeneratorTarget*, std::set<std::basic_string<char> > >' has no member
 >     named 'emplace_hint'

 > But all the failures occur on gcc-20...

 > I looke at my autobuilder, and it uses gcc-4.8.2, and cmake builds fine
 > with that...

 > gcc-4.8 was released in March 2013, which will be almost 5 years ago
 > when we tag LTS 2018.02. So maybe we can keep using cmake-3.9 up until
 > 2018.02, then update our requirements to require a host gcc >= 4.8m
 > which will allow us to bump cmake to 3.10.

 > I agree that, with time passing, more and more packages will require
 > C++11, so it will make sense to require proper C++11 support for the
 > host compiler.

Yes, maybe that is indeed the best way forward - Post 2018.02 that is.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash

[Thomas Petazzoni]

Hello,

On Mon, 18 Dec 2017 23:15:42 +0100, Peter Korsgaard wrote:

>  > I looke at my autobuilder, and it uses gcc-4.8.2, and cmake builds fine
>  > with that...  
> 
>  > gcc-4.8 was released in March 2013, which will be almost 5 years ago
>  > when we tag LTS 2018.02. So maybe we can keep using cmake-3.9 up until
>  > 2018.02, then update our requirements to require a host gcc >= 4.8m
>  > which will allow us to bump cmake to 3.10.  
> 
>  > I agree that, with time passing, more and more packages will require
>  > C++11, so it will make sense to require proper C++11 support for the
>  > host compiler.  
> 
> Yes, maybe that is indeed the best way forward - Post 2018.02 that is.

It feels a bit annoying to make such a change that would impact all
Buildroot users, just for the sole reason of an optimization down into
CMake.

I agree that we won't be able to avoid using a C++11 compiler on the
host at some point. I'm just trying to see if we can avoid this when
reasonably possible.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com