Denis Dupeyron wrote:

> 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."

Ebuilds shouldn't die on anything according to the non-interactive portage
philosophy.  I don't know how official that philosophy is though.

> 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 ?

No, that would be a major pain in the ass for anyone wanting to use -fast-math,
which does have legitimate uses.

> 2) If yes, are there any other flags that ebuilds should die on ?

There's a million, and they're constantly changing.  For example,
-frename-registers is generally safe on GCC 3.4, broken in 4.0, and enabled by
default on 4.1.

> 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.

Users playing with CFLAGS get to keep the pieces.  Trying to dummy-proof the
system doesn't help anyone but the dummies. ;)

--de.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to