1 |
On Tue, 11 Sep 2018 12:44:38 +0300 |
2 |
Alon Bar-Lev <alonbl@g.o> wrote: |
3 |
|
4 |
I'm personally in favour of not allowing -Werror |
5 |
to be in build system unconditionally. |
6 |
|
7 |
Maintainer is free to implement --enable-werror any way |
8 |
it's convenient to run on their own extended sanity checks |
9 |
and optionally expose it to users. Be it USE flag or |
10 |
EXTRA_ECONF option. |
11 |
|
12 |
> I would like to suggest a modify our policy with the following |
13 |
> exception clause: Package maintainer may decide to keep upstream |
14 |
> -Werror as long as he is willing to resolve all issues resulting from |
15 |
> -Werror as if it was a blocker bug. |
16 |
|
17 |
Do you intend to keep -Werror for case when ebuild goes |
18 |
stable as well? |
19 |
|
20 |
If you do it then what is your workflow to fix breakages |
21 |
appearing in stable packages caused by minor environment |
22 |
changes like toolchain tweaks? |
23 |
|
24 |
Add another round of stabilization on each arch team? It |
25 |
sounds like your default assumption that code needs to be |
26 |
changed in a semantically significant way: add annotations |
27 |
that might not like some toolchains, remove unused code. |
28 |
|
29 |
Or patch package in-place without bumping? None of options |
30 |
sound optimal compared to dropping -Werror. |
31 |
|
32 |
> The package maintainer decision may be based on the package state and |
33 |
> the relationship with upstream, but basically, it is his decision as |
34 |
> long as issues are fixed in timely manner, it is his overhead after |
35 |
> all. |
36 |
|
37 |
I agree that maintainer's will and upstream's will should be |
38 |
respected and it's not something needs to be absolutely |
39 |
enforced all the time. |
40 |
|
41 |
Personally I disagree -Werror on end-user machine is worth |
42 |
it (or cppcheck, or coverity round-trip run is worth running |
43 |
on user's machine unconditionally). |
44 |
|
45 |
Unused variable is a good example of typical benign warning: |
46 |
it was there all the time, it's not a new bug and does not |
47 |
warrant need for an immediate fix. |
48 |
|
49 |
Toolchain just happend to get better at control flow graph |
50 |
analysis. Fix can easily wait for next release and save |
51 |
everyone's time. |
52 |
|
53 |
Not every user is willing to create bugzilla account and figure |
54 |
the path of reporting the breakage. Especially if there are |
55 |
many breakages like that. Getting multiple various errors is |
56 |
probable if one imagines -Werror to be commonly allowed. |
57 |
This is user's overhead. Not just maintainer's. |
58 |
|
59 |
Gentoo does not normally run tests on user's systems either. |
60 |
Tests are arguably a lot more precise in pointing out real |
61 |
problems in software. |
62 |
|
63 |
> ARGUMENT: If a package compiled in the past using toolchain X then it |
64 |
> must continue to do so with any future toolchain. |
65 |
> |
66 |
> I do not understand when "build" is the test for runtime |
67 |
|
68 |
The argument was about "keep compiling". Runtime |
69 |
behaviour is a separate issue and (in my opinion) is an |
70 |
orthogonal topic. |
71 |
|
72 |
On another note I occasionally like to build Gentoo with |
73 |
clang's -Weverything (or equivalent set of gcc CFLAGS) |
74 |
to get the idea if there is a good useful warning out there |
75 |
to put into -Werror= list. |
76 |
|
77 |
Explicit -Werror= list allows code not to regress. But even |
78 |
that is prone to harmless infelicities in libc headers that |
79 |
can't be easily fixed. |
80 |
|
81 |
In case of opensc it just does not compile even if I pass -Wno-error: |
82 |
$ CC=clang CFLAGS="-O2 -Weverything -Wno-error" emerge -v1 opensc |
83 |
|
84 |
I don't expect 'opensc' upstream to fix this use for me |
85 |
and don't see it worth reporting to bugzilla. |
86 |
|
87 |
But maybe I'm wrong? |
88 |
|
89 |
-- |
90 |
|
91 |
Sergei |