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.
Description: OpenPGP digital signature