[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.

[Duncan]

"Denis Dupeyron" <calchan@g.o> posted
7c612fc60607091424s467c27e4n665fc3dd4ee2116a@××××××××××.com, 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@g.o mailing list