[OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11

richard.purdie at linuxfoundation.org richard.purdie at linuxfoundation.org
Mon May 13 11:40:53 UTC 2019


On Mon, 2019-05-13 at 14:34 +0300, Mark Hatle wrote:
> On 5/11/19 4:42 AM, Khem Raj wrote:
> > 
> > Can we require centos7 and other hosts which use old compilers to 
> > install the additional packages to have newer compilers ? e.g. for 
> > centos installing devtoolset-7 will fix this issue
> 
> I think we need to consider disabling this by default, as Ross
> indicated he
> wasn't sure it was really required, as well as consider the c++14
> patch (if
> standard CentOS supports C++-14).
> 
> I do think it's reasonable to try to patch this component, assuming
> it can be
> done in a reasonable way with a reasonable end result.  (10-lines is
> pretty easy
> to understand/support, 1000 lines... no so much.)
> 
> However, once we get past one component into multiples, then we need
> a better
> answer.  Either a set of buildtools the user can build/download, or
> items
> standard distributions have that they can install.
> 
> Unfortunately CentOS 7 (and corresponding RHEL) is ancient by
> compiler
> standards, but is heavily used as a replacement is not yet ready.  So
> this is a
> problem we'll need to deal with for a while still.  Until CentOS 7
> era is really
> no longer heavily used I think we don't have a choice here but to
> deal with this
> one way or another.

We avoided the problem by dropping the dependency so we're ok again for
now. We haven't required special things be installed on hosts as it
increases the documentation problem quite a lot. We run our autobuilder
test workers fairly standard for this reason.

The problem is going to get worse over time and the other solution
could be we require one of our own buildtools-tarballs installed too.
We have used this approach on our autobuilder workers in the past.

I am keen to avoid extra distro specific documentaiton (and patches to
detect the conditions) if we can help it...

Cheers,

Richard






More information about the Openembedded-core mailing list