On Tue, 11 Sep 2018 12:44:38 +0300
Alon Bar-Lev <alo...@gentoo.org> wrote:
I'm personally in favour of not allowing -Werror
to be in build system unconditionally.
Maintainer is free to implement --enable-werror any way
it's convenient to run on their own extended sanity checks
and optionally expose it to users. Be it USE flag or
EXTRA_ECONF option.
> I would like to suggest a modify our policy with the following
> exception clause: Package maintainer may decide to keep upstream
> -Werror as long as he is willing to resolve all issues resulting from
> -Werror as if it was a blocker bug.
Do you intend to keep -Werror for case when ebuild goes
stable as well?
If you do it then what is your workflow to fix breakages
appearing in stable packages caused by minor environment
changes like toolchain tweaks?
Add another round of stabilization on each arch team? It
sounds like your default assumption that code needs to be
changed in a semantically significant way: add annotations
that might not like some toolchains, remove unused code.
Or patch package in-place without bumping? None of options
sound optimal compared to dropping -Werror.
> The package maintainer decision may be based on the package state and
> the relationship with upstream, but basically, it is his decision as
> long as issues are fixed in timely manner, it is his overhead after
> all.
I agree that maintainer's will and upstream's will should be
respected and it's not something needs to be absolutely
enforced all the time.
Personally I disagree -Werror on end-user machine is worth
it (or cppcheck, or coverity round-trip run is worth running
on user's machine unconditionally).
Unused variable is a good example of typical benign warning:
it was there all the time, it's not a new bug and does not
warrant need for an immediate fix.
Toolchain just happend to get better at control flow graph
analysis. Fix can easily wait for next release and save
everyone's time.
Not every user is willing to create bugzilla account and figure
the path of reporting the breakage. Especially if there are
many breakages like that. Getting multiple various errors is
probable if one imagines -Werror to be commonly allowed.
This is user's overhead. Not just maintainer's.
Gentoo does not normally run tests on user's systems either.
Tests are arguably a lot more precise in pointing out real
problems in software.
> ARGUMENT: If a package compiled in the past using toolchain X then it
> must continue to do so with any future toolchain.
>
> I do not understand when "build" is the test for runtime
The argument was about "keep compiling". Runtime
behaviour is a separate issue and (in my opinion) is an
orthogonal topic.
On another note I occasionally like to build Gentoo with
clang's -Weverything (or equivalent set of gcc CFLAGS)
to get the idea if there is a good useful warning out there
to put into -Werror= list.
Explicit -Werror= list allows code not to regress. But even
that is prone to harmless infelicities in libc headers that
can't be easily fixed.
In case of opensc it just does not compile even if I pass -Wno-error:
$ CC=clang CFLAGS="-O2 -Weverything -Wno-error" emerge -v1 opensc
I don't expect 'opensc' upstream to fix this use for me
and don't see it worth reporting to bugzilla.
But maybe I'm wrong?
--
Sergei
