1 |
(Sorry that this mail does not contain the proper "References:"; |
2 |
I am not a regular reader of this list and therefore cannot "reply"). |
3 |
|
4 |
Ryan Hill <dirtyepic@g.o> wrote: |
5 |
|
6 |
> USE flags should not affect CFLAGS unless there is a very good reason |
7 |
|
8 |
A valid reason should be that upstream would prefer to add these flags. |
9 |
|
10 |
Please note that usually upstream should know best which CFLAGS |
11 |
to add, because upstream is usually the only instance fully familiar |
12 |
with all details of the code (at least, upstream _should_ be so :) ). |
13 |
In fact, a lot of flags are not only safe to add but really *should* |
14 |
be added if the code was written with such flags in mind. |
15 |
|
16 |
For instance, if the code contains no type-punning, -fstrict-aliasing |
17 |
can be safely added, and it would be a waste of upstream's effort to |
18 |
possibly avoid type-punning if it is not added in such a case. |
19 |
Another example is -fmerge-all-constants where usually code is written |
20 |
having in mind that optimizations due to this flag will happen |
21 |
(e.g. certain constants are sometimes redundantly repeated in the |
22 |
source [for convenience or possibly local change] instead of making |
23 |
sure that they occur only once). |
24 |
|
25 |
In fact, most CFLAGS are there for a reason (adding them is only |
26 |
"ricing" if you do it without respecting details of the code). |
27 |
|
28 |
So who should add the CFLAGS appropriate for a particular package? |
29 |
The user cannot do it seriously for every package separately (this |
30 |
option is reasonable only for binary distributions). |
31 |
Some packages try to force CFLAGS on the user without asking, but |
32 |
this is not very good, because the user might have a valid reason to |
33 |
disagree with upstream's decisions. For instance, a flag might be |
34 |
broken in a particular compiler version. |
35 |
|
36 |
So the natural thing is to give the user the choice whether to follow |
37 |
upstream's recommendations or not. And the way of choice in gentoo is |
38 |
usually done by USE flags. I would consider it very strange if |
39 |
a _purely political_ decision would forbid convenient choices for |
40 |
user and upstream. |
41 |
|
42 |
The debug USE flag in eix is also about convenience for the user: |
43 |
If eix segfaults, it prints instructions how to produce a backtrace |
44 |
in such a way which is most likely useful for upstream to locate |
45 |
the problem. |
46 |
Currently, these instructions are rather simple, because they can |
47 |
refer to USE=debug. Omitting the debug USE flag would complicate |
48 |
the instructions, making debugging less convenient for the user |
49 |
and for upstream. Why should such an inconvenience be necessary? |
50 |
Only to follow some abstract fundamental policy about what USE flags |
51 |
are allowed to do? If this is really the case then perhaps there is |
52 |
something wrong with that policy. |
53 |
|
54 |
To avoid a misunderstanding: For packages for which upstream has no |
55 |
particular preference for the CFLAGS, I agree that it would be very |
56 |
strange to add CFLAGS by means of a USE flag. But if there _is_ such |
57 |
a recommendation, I would not like to see it ignored in Gentoo |
58 |
just for political reasons. |
59 |
|
60 |
Best Regards |
61 |
Martin Väth |