| Message ID | 20171210233349.24682-1-mlang@blind.guru |
|---|---|
| State | Accepted |
| Headers | show |
| Series | package/cmake: bump version to 3.10.0 and add license hash | expand |
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
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 <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?
________________________________________ 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@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@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
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, 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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
>>>>> "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.
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
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
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(-)