1 |
On Thu, 1 Jul 2010 14:53:19 +0200 (CEST) |
2 |
Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
3 |
|
4 |
> (Sorry that this mail does not contain the proper "References:"; |
5 |
> I am not a regular reader of this list and therefore cannot "reply"). |
6 |
> |
7 |
> Ryan Hill <dirtyepic@g.o> wrote: |
8 |
> |
9 |
> > USE flags should not affect CFLAGS unless there is a very good reason |
10 |
> |
11 |
> A valid reason should be that upstream would prefer to add these flags. |
12 |
> |
13 |
> Please note that usually upstream should know best which CFLAGS |
14 |
> to add, because upstream is usually the only instance fully familiar |
15 |
> with all details of the code (at least, upstream _should_ be so :) ). |
16 |
> In fact, a lot of flags are not only safe to add but really *should* |
17 |
> be added if the code was written with such flags in mind. |
18 |
> |
19 |
> [...] |
20 |
|
21 |
Upstream is free to use whatever CFLAGS they see fit, as long as the user has |
22 |
the option of disabling them. This is simply done by appending the user's |
23 |
CFLAGS to those of the build system. But this has nothing to do with USE |
24 |
flags. |
25 |
|
26 |
> So the natural thing is to give the user the choice whether to follow |
27 |
> upstream's recommendations or not. And the way of choice in gentoo is |
28 |
> usually done by USE flags. |
29 |
|
30 |
USE flags control package options - whether to include support for foo, |
31 |
install extra documentation, build against either of lib-a or lib-b, etc. |
32 |
They should not affect compiler flags. Some exceptions are pch, profiling, |
33 |
and critical packages that really, really should be built with upstream's |
34 |
compiler flags but then people whine so much about "Gentoo being about choice" |
35 |
that someone adds a "custom-cflags" USE. |
36 |
|
37 |
The way to control compiler flags in Gentoo is CFLAGS. |
38 |
|
39 |
> The debug USE flag in eix is also about convenience for the user: |
40 |
> If eix segfaults, it prints instructions how to produce a backtrace |
41 |
> in such a way which is most likely useful for upstream to locate |
42 |
> the problem. |
43 |
> Currently, these instructions are rather simple, because they can |
44 |
> refer to USE=debug. Omitting the debug USE flag would complicate |
45 |
> the instructions, making debugging less convenient for the user |
46 |
> and for upstream. Why should such an inconvenience be necessary? |
47 |
|
48 |
If all --enable-debug does is add -g to CFLAGS, why can't you just say that? |
49 |
Or maybe point them to http://www.gentoo.org/proj/en/qa/backtraces.xml? |
50 |
|
51 |
If --enable-debug does more than that then having a debug USE flag is |
52 |
perfectly fine. I don't have a problem with --enable-debug adding -g as well |
53 |
as (eg.) enabling assertions because if you're using USE="debug" you're |
54 |
probably using -g already. |
55 |
|
56 |
> To avoid a misunderstanding: For packages for which upstream has no |
57 |
> particular preference for the CFLAGS, I agree that it would be very |
58 |
> strange to add CFLAGS by means of a USE flag. But if there _is_ such |
59 |
> a recommendation, I would not like to see it ignored in Gentoo |
60 |
> just for political reasons. |
61 |
|
62 |
Again, we're not ignoring CFLAGS and we're not doing this for abstract or |
63 |
political reasons. This simply isn't what the debug USE flag is for. |
64 |
|
65 |
|
66 |
-- |
67 |
fonts, gcc-porting, and it's all by design |
68 |
toolchain, wxwidgets to keep us from losing our minds |
69 |
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |