From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash
Date: Sun, 17 Dec 2017 18:39:11 +0100 [thread overview]
Message-ID: <20171217173911.GA7491@scaer> (raw)
In-Reply-To: <20171216133439.58247290@windsurf>
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. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2017-12-17 17:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-10 23:33 [Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash Mario Lang
2017-12-12 6:07 ` Thomas Petazzoni
2017-12-12 11:30 ` Thomas Petazzoni
2017-12-16 10:52 ` Mario Lang
2017-12-16 10:52 ` [Buildroot] FW: " Kees van Unen
2017-12-16 12:34 ` [Buildroot] " Thomas Petazzoni
2017-12-17 17:39 ` Yann E. MORIN [this message]
2017-12-18 22:15 ` Peter Korsgaard
2017-12-19 8:39 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171217173911.GA7491@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.