On 7/11/06, Ryan Hill <[EMAIL PROTECTED]> 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@gentoo.org mailing list
