1 |
On Fri, 2 Jul 2010 15:29:44 +0200 (CEST) |
2 |
Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
3 |
|
4 |
> Ryan Hill <dirtyepic@g.o> wrote: |
5 |
> |
6 |
> > If your build system sets -ffast-math or -fstrict-aliasing |
7 |
> > then the user can disable this by setting -fno-fast-math |
8 |
> > or -fno-strict-aliasing in their CFLAGS. |
9 |
> |
10 |
> Just because some flags have "counter"-flags by accident, |
11 |
> this does not hold for all flags. It is more reasonable to have |
12 |
> other means that the flags are not modified in the first place. |
13 |
|
14 |
I can't think of any flags that don't have a corresponding counter flag, |
15 |
other than -m flags. At least, all -f and -W flags have opposite -fno and |
16 |
-Wno versions, even if they're not explicitly documented. |
17 |
|
18 |
> In fact, when I first introduced adding of CFLAGS, there were |
19 |
> lot of complaints that this is evil and must not be done. |
20 |
> I can understand this point of view (even if I know that |
21 |
> certain CFLAGS should be used with the code and I would also |
22 |
> prefer to have them to find possibly hidden bugs), so we |
23 |
> compromised by having an option: |
24 |
> With this option everybody could live well, since users with |
25 |
> special settings will not run into trouble because undesired |
26 |
> flags are added, and other users could just select the USE flag |
27 |
> and have the benefits of appropriately optimized code. |
28 |
> Up to now, that is, when we have this IMHO needless discussion |
29 |
> that an option should not be an option. |
30 |
|
31 |
If you as upstream have written your code in a way that it benefits from |
32 |
certain flags (like -ffast-math, -fstrict-aliasing, -fvisibility-hidden, |
33 |
etc.) then I think enabling those flags by default is the right thing to do. |
34 |
There are many packages in the tree that do this, so if people are |
35 |
complaining about it then it's their problem, not yours. ;) |
36 |
|
37 |
> I hope that this answers also the question of |
38 |
> Alec Warner <antarus@g.o>: |
39 |
> |
40 |
> : I am confused. If you want the users to use a default set of CFLAGS |
41 |
> : you should set this in your build system (autotools, cmake, whatever). |
42 |
> : [...] |
43 |
> : I believe the above link seems to describe what you are looking to do |
44 |
> : using autotools. |
45 |
> |
46 |
> Technically, I have no problem to force in configure.ac that certain |
47 |
> CFLAGS are used (unless somebody patches the configure.ac, of course). |
48 |
> The problem is that it is not good to force this if the user disagrees |
49 |
> (or maybe even unless he explicitly agrees), i.e. it should be an |
50 |
> option which the user really has. (If this option should only be |
51 |
> documented in some INSTALL text or in the ./configure output, |
52 |
> most users do not really have this option, because they would not |
53 |
> even know about it.) |
54 |
|
55 |
Maybe the best option in this case really is to use "custom-cflags". This |
56 |
gives the user the option of explicitly opting out of your recommended |
57 |
configuration, while the majority would build the package to your |
58 |
specifications. I think this would make everyone happy (?). |
59 |
|
60 |
|
61 |
-- |
62 |
fonts, gcc-porting, and it's all by design |
63 |
toolchain, wxwidgets to keep us from losing our minds |
64 |
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |