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