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

[Denis Dupeyron]

On 7/11/06, Ryan Hill <dirtyepic.sk@×××××.com> wrote:
> Their phrase, not mine. ;)  I think the idea is you should be able to emerge -e
> world and walk away and not have anything interrupt the process thus requiring
> the user interact with the system.

Well yes, but an ebuild that dies, whatever the reason, hasn't much to
do with interactivity.

> > If a package is known not to work with a certain flag, being able to
> > emerge it won't change the fact that it doesn't run.
>
> If a package is known to not work with a certain flag it should be filtered so
> it does run.

What will follow isn't only for you. You guys are focusing on the
die/filter alternative. Maybe you haven't noticed but I have never
stated that I'd prefer ebuilds to die or filter. What I wanted to
discuss is can't we do something globally to avoid these bugs coming
in, so that we can focus on something else. I don't care yet if it's
filtering or dying. And never did I talk about educating the masses.

> Do you mean for ebuilds that knowingly break with -ftracer, or for everything?
> There are packages that expect to be built with certain flags;  not -ftracer,
> but others.  Fex, libao needs -ffast-math ;).  Also, what about ebuilds that do
> use -fprofile, like gcc itself?  I know toolchain.eclass strips all flags, I'm
> just using it as an example.

I explained I was talking about a global system, with a possibility
for ebuilds/users that wanted/needed it to opt out. It's much easier
to "unblock" --fast-math for libao than going through idontknowhowmany
bugs about the same number of packages that break with --fast-math,
for example.

> If you mean just for packages that break with certain flags then absolutely.
> But such a mechanism would have to be maintained for every different GCC
> version, since -fprofile might not invoke -ftracer in every version, and indeed
> some versions might not even recognize -fno-tracer and bail with an error.

Let's count together the number of GCC versions we should really care
about. 3.4, 4.1, any others ?

> Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to
> automate this in any sane way.

Automate what ?

> Right, but how are people supposed to learn something is dangerous if all the
> sharp edges have been filed off?  And how can you decide which flags are "bad"
> and "good" on a global level when for the most part compiler parameters are akin
> to black magic?

Since when is being a learning tool one of the goals of Gentoo ?

Denis.
-- 
gentoo-dev@g.o mailing list