On 7/10/06, Ryan Hill <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. -- email@example.com mailing list