"Denis Dupeyron" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 09 Jul 2006 23:24:24 +0200:
> 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." As a user active on the lists/groups (and the same would go for forums), and opposing both Ryan Hill's and Richard Fish's opinions, I absolutely agree with Paul on this! My reason for doing so is that I've seen users say they use it with no ill effects they can see on their system. Of course, we know that's because where it has caused problems enough to bug, it has been filtered, but obviously the users don't know that, or are *relying* on it, *not* a good idea IMO. If ebuilds start dying on it, those users will soon see how many things it /does/ break, and should quickly change their minds. > 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 ? I'd say yes -- provided there's documentation (say a bug where removing it cured the bug) that it's an actual problem with that package. If a maintainer has put the filterflag in simply peremptorily, as I'd argue this particular flag might warrant, that's a different question. IMO, that would be counterproductive, since a user simply removing the die, redigesting, and continuing, would have likely convinced himself of the safety of that flag. > 2) If yes, are there any other flags that ebuilds should die on ? I'd say very few, keeping in mind portage's non-interactive philosophy (as Ryan mentioned). Very few are /that/ profoundly stupid, and require someone hit the practitioner upside the head with a cluebat. > 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. Given the rarity of a flag as extreme as -ffast-math, I'd say that shouldn't normally be the case. Do note that -ffast-math is itself a meta-flag, enabling several others. I'd /not/ recommend dying on the individual flags, thereby giving those that would use -ffast-math /that/ way to do so if they /insist/ on it -- and have read the documentation well enough to know about it. > 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. I'd favor a USE_EXPAND type flag that could take several "I'm broken so don't file bugs" type strings, which could be individually tested for in the various ebuilds (and/or profiles), while at the same time grouping them automatically for purposes of emerge --info and therefore bug reports. amd64 tests for such "IM_BROKEN" type vars in their development profiles (would be 2006.1 for example ATM), and I believe gcc tested for (and may still) a similar var during part of the 4.0 process, where users agreed not to file bugs unless they came with patches. Having these all in the same place, perhaps as individual values of a PORTAGE_I_DELIBERATELY_CHOOSE_TO_BE_BROKEN var or the like, where emerge --info would report it yet ebuilds/profiles could test for the presence of individual strings, would be a very good thing IMO. A function or two could then be added to eutils to aid in standardizing the testing for such strings and encourage use of the standard grouping. If that or a similar solution is chosen, then one such string could be created for -ffast-math. Once that was done, a test for that string could be set in profiles/base or the like, setting up the test for -ffast-math system-wide, whereupon it could be eliminated from the individual ebuilds. That would also provide a suitable single-shot environment based solution for the user, as well, in the case they wanted to override the system test for an individual ebuild. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list
