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

[Denis Dupeyron]

On 7/10/06, Ryan Hill <dirtyepic.sk@×××××.com> wrote:

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

Correct me if I'm wrong, but this has nothing to do with being
interactive or not. To me, an ebuild that dies (intentionally or due
to a build error) isn't interactive at all.

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

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. Plus, if the
solution is considered good for python, I don't understand why it
wouldn't be good for any other package. Are you saying that Paul's
proposition of having the python ebuild die on use of --fast-math
isn't good ? If yes, why ? And what is your better idea ?

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

Which is exactly the reason why we could benefit of something that
enables us to manage this in a clean and safe way. I'm not saying I
have a candidate for that "something", but I wanted to discuss if
there was an interest in it.

Let's take again the example of -ftracer which can be enabled by the
-fprofile-use meta-flag. Imagine we have a mechanism somewhere (again,
the reason I'm being vague is that my point isn't to discuss
implementation just yet) that adds -fno-tracer to CFLAGS. In this
case, you're covered wether -ftracer was added directly on indirectly
by fprofile-use, which actually simplifies the number of flags that
you need to blacklist. Thus ebuilds don't have to take care of it,
bugs don't pour into bugzie, and Jakub can avoid overheating.

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

I'm one of those devs who care for our users. I think it's dangerous
to try and categorize users in, for example, dummies and non-dummies,
as you say. Who are we to judge this or that user is a dummy ? Plus,
we all are the dummy of somebody else.

Anyway, I was thinking more in terms of making the job of developers,
bug wranglers, and poor old bugzilla easier, cleaner, safer. How many
bugs do we have that are due to dangerous flags ? How much time and
effort could we save if we didn't have those ? Also, I was thinking
that if a good solution was found to deal with a dangerous flag in a
certain package, maybe it was a good idea to extend this solution to
other packages. And finally, if said solution becomes common, maybe
it's a good idea to make it system-wide with a possibility to override
the setting by the user or the ebuild. It seems we already have
per-package CFLAGS, so part of this, at least, is already implemented.


On 7/10/06, Richard Fish <bigfish@××××××××××.org> wrote:

> My (user) opinion is that ebuilds should not die on CFLAGS, at least
> not until per-package CFLAGS are implemented.

Why ? Stating your opinion without any justification isn't really
constructive. And same as above : being able to emerge a package that
won't run doesn't help you more.

> Now if someone is crazy enough to enable -ffast-math globally or
> specifically for python in that situation, well, die, spin the cpu fan
> backwards, melt the hard disk down and sell it for scrap, whatever you
> want!

Same as above again, replace 'dummy' with 'crazy'.

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