1 |
On Thu, 1 Jul 2010 23:44:17 +0200 (CEST) |
2 |
Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
3 |
|
4 |
> Ryan Hill <dirtyepic@g.o> wrote: |
5 |
> > Upstream is free to use whatever CFLAGS they see fit, as long as the |
6 |
> > user has the option of disabling them. This is simply done by appending |
7 |
> > the user's CFLAGS to those of the build system. |
8 |
> |
9 |
> Since it is obvious that by _appending_ only the user's CFLAGS to your |
10 |
> own, you do not give him the option of disabling your own, the more |
11 |
> natural way to do this is to make it configurable in the build system, |
12 |
> e.g. by a ./configure option. |
13 |
|
14 |
> Speaking from the author's perspective: There should be a way |
15 |
> to write code appropriate for a specific compiler flag and to |
16 |
> assume that most users will then actually compile the package |
17 |
> with the corresponding flag. |
18 |
> If a user explicitly does not want to do this, this is fine, |
19 |
> but the ebuild should have a way to make sure that this only |
20 |
> happens if it is really the intention of the user. |
21 |
|
22 |
If your build system sets -ffast-math or -fstrict-aliasing then the user can |
23 |
disable this by setting -fno-fast-math or -fno-strict-aliasing in their |
24 |
CFLAGS. If they don't, your flags are used. Isn't this exactly what you're |
25 |
asking for? |
26 |
|
27 |
> > But this has nothing to do with USE flags. |
28 |
> |
29 |
> The usual way in gentoo to pass upstream's ./configure options |
30 |
> to the user is via USE flags. |
31 |
|
32 |
Just because you've chosen to make compiler flags controlled by configure |
33 |
options in your package does not mean they should be USE flags. |
34 |
|
35 |
> > The way to control compiler flags in Gentoo is CFLAGS. |
36 |
> |
37 |
> CFLAGS in Gentoo are the way to pass CFLAGS to the build system. |
38 |
> Nothing more, nothing less. |
39 |
> You want to make it the _only_ way to control compiler flags. |
40 |
> Since Gentoo is lacking any other mechanism allowing an ebuild author |
41 |
> or upstream to set default CFLAGS (binary distributions do not need |
42 |
> such things, because the packager should compile the package with the |
43 |
> appropriate flags anyway), this would mean _in practice_: |
44 |
> Either upstreams forces its flags upon the user, or most users will |
45 |
> *not* build the package according to the package authors' suggestions |
46 |
> (and most will probably not even realize this). |
47 |
> You cannot seriously believe that one of these possibilities is better |
48 |
> than to make the things transparent to the user and to give him |
49 |
> the choice _in practice_ by means of a USE flag. |
50 |
|
51 |
I honestly don't understand what you're talking about. You're not making |
52 |
sense. Set your CFLAGS in your build system. If people need to override |
53 |
them they can specifically do so. Otherwise your options will be used, like |
54 |
you want. |
55 |
|
56 |
If you feel so strongly that your upstream-chosen-and-approved flags should |
57 |
always be used then add a "custom-cflags" USE flag and call strip-flags if |
58 |
it's disabled. While this is strongly discouraged, it's ultimately up to the |
59 |
maintainer to decide to use it. |
60 |
|
61 |
> > If --enable-debug does more than that then having a debug USE flag is |
62 |
> > perfectly fine. I don't have a problem with --enable-debug adding -g |
63 |
> > as well as (eg.) enabling assertions |
64 |
> |
65 |
> This is one of the things which are happening. More precisely, |
66 |
> not disabling assertions by *not* adding -DNDEBUG (and e.g. not |
67 |
> breaking code by not adding -flto with the -g). |
68 |
> Admittedly, it is not overly complex what USE=debug does, but - |
69 |
> well, it enables the only debugging support which is available |
70 |
> which in this case is all related with CFLAGS in some way or |
71 |
> another. |
72 |
|
73 |
Then what are we arguing about? :) -DNDEBUG is not a CFLAG, it's a |
74 |
preprocessor definition and is a perfectly valid reason for a debug USE flag. |
75 |
|
76 |
-- |
77 |
fonts, gcc-porting, and it's all by design |
78 |
toolchain, wxwidgets to keep us from losing our minds |
79 |
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |