1 |
Dear devs, |
2 |
|
3 |
In bug #139412, I ask Paul de Vriese why he thinks python should die |
4 |
on --fast-math instead of just filtering it. Here's his answer : |
5 |
|
6 |
"Denis, quite simple. -ffast-math is broken and short-sighted for a global flag. |
7 |
Filtering gives the shortsighted message that it works globally, while it is |
8 |
not suited for any package not specifically tested for it. As it breaks python, |
9 |
dieing makes people understand that it does not work on python. It is better |
10 |
than the alternative of not looking for it at all." |
11 |
|
12 |
This, for me, triggers 3 questions that are gentoo-dev@ material : |
13 |
|
14 |
1) Should all ebuilds that currently filter --fast-math die on its |
15 |
presence instead of filtering it ? |
16 |
|
17 |
2) If yes, are there any other flags that ebuilds should die on ? |
18 |
|
19 |
3) Suppose that -ftracer, for example, is one of those, and knowing |
20 |
that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also |
21 |
die on use of -fprofile-use ? It's only an example, this situation |
22 |
will exist for other pairs of flags. |
23 |
|
24 |
The hidden question behind these three is : shouldn't we have a |
25 |
"something" that enables us to safely handle this kind of situations ? |
26 |
Like some kind of system- and/or architecture-wide flag mask that |
27 |
could be overriden by the ebuild and/or the user (at his own risk) ? |
28 |
This could potentialy reduce the number of bugs that poor old bugzie |
29 |
has to cope with, and simplify ebuild writing and maintenance. |
30 |
|
31 |
If we already have such a thing, I'm sure you guys know where the |
32 |
cluebat is... But in any case, questions 1), 2) and 3) still need to |
33 |
be answered. |
34 |
|
35 |
Denis. |
36 |
-- |
37 |
gentoo-dev@g.o mailing list |