[OpenWrt-Devel] [PATCH] build: make GCC version 6+ minimal host build requirement

[Yousong Zhou]

On Tue, 12 Nov 2019 at 17:12, Petr Štetiar <ynezz at true.cz> wrote:
>
> Yousong Zhou <yszhou4tech at gmail.com> [2019-11-12 16:26:14]:
>
> Hi,
>
> > Not quite sure how much benefit enforcing -Wextra can bring to the
> > whole code base.
>
> I'm adding -Wextra for some time already to any C project I touch, nobody has
> objected against it so far. I'm adding it because I think, that the latest
> compilers are producing usable warnings, less false positives and that it
> should be one of the standard hardening options for any network facing
> project. I see -Wextra just as another pair of review eyes for me, even if
> it's provided by the machine.

I agree, especially when it comes to quality assurance.

>
> It's just older GCC versions making -Wextra PITA, so if we decide to keep
> support for gcc-4.8+, then it would probably make sense to enable -Wextra for
> gcc6+.

This is not bad.  Only feeding those options to toolchains with decent
support of them, with less confusing false positives.  Users with
better toolchains will notice them and users with old toolchains still
benefit from it.

>
> > Excluding support for vanilla CentOS7 will certainly cause inconvenience for
> > large numbers of users.
>
> Well, I don't see anything bad about sunsetting of old tools. This is master,
> so next OpenWrt release somewhere in the 2020, so probably not a big deal,
> right? They're going to install python3 anyway as well.
>
> > That is probably more so to serious industrial users.
>
> If I'm able to install gcc-4.8 on my latest stable Debian, then I assume, that
> it should be relatively straight forward to install some decent GCC version on
> <your-stable-distro> as well.

How old to be old that is a question to ask.  In the specific case of
rhel7/centos7, I suppose it is still widely deployed and used.  It is
supposed to have at least 10 years support backed by redhat.  Its
"retirement" is supposed to be at year 2024 with extended life-cycle
support not yet decided.

Nah, I cannot speak for/represent rhel/centos community.  I have never
owned a red hat.

Python3 has been around for more than 10 years and it's no surprise
that it should be readily available.  Even the eol centos6 could have
it with epel enabled.  With centos7, I am not aware of any official
ways to install newer versions of software, only bugfixes.  I tried
for a few times with packages provided by SoftwareCollections.org, but
it's definitely not "straightforward" enough in my opinion.

>
> If we decide to keep gcc-4.8 support, wouldn't it make sense to use gcc-4.8 on
> buildbots as well? You know, in order to catch similar issues during QA
> process.
>
> I can certainly add gcc-4.8, gcc-4.9, gcc-5 to the CI compiler mix (currently
> has gcc-7, gcc-8, gcc-9 and clang-9 compilers), but this is going to result in
> the 6 additional compile/run tests (3 * release/debug), so it makes me wonder
> if it's really worth the resources/efforts.
>
> -- ynezz

I think we agree that whatever the decision is at the end, it's just
trade-off.  My concern is that closing doors for support of gcc 4.8 is
being too rigid.  Note that we are talking about host build with host
toolchain whose input we control and whose product only runs on the
host itself at build times.

Regards,
                yousong

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel