package/cmake: bump version to 3.10.0 and add license hash

Signed-off-by Mario Lang <[email protected]>

---
 package/cmake/cmake.hash | 5 +++--
 package/cmake/cmake.mk   | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

Quoted 5 lines · Mario Lang

Signed-off-by Mario Lang <[email protected]>

---
 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 ?

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 ?

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.

Quoted 4 lines

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.

Quoted 1 line

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?

Quoted 1 line

To move to C++11 was apparently intentional, and not an oversight.

Quoted 6 lines

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

Signature · 7 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

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.

Quoted 7 lines

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.

Quoted 3 lines

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.