On Mon, Oct 01, 2012 at 10:15:31AM +0100, Ciaran McCreesh wrote: > On Mon, 1 Oct 2012 02:01:32 -0700 > Brian Harring <ferri...@gmail.com> wrote: > > Implicit labels context is build+run.
<snip> > Your rules require a handler to say "have I seen any dep: blocks > further up the tree than my current position? If yes, handle this dep: > block one way; otherwise, handle it a different way". Given that there's an implicit top-level, that's always a "yes" so there is no such "special"-case decision required. > With labels, all > you do is initialise the label stack with build+run, and then no > special case handling is required. > In practical terms, that's the exact same thing as initialising with a defined context. And as shown, your proof of "special-case" is bogus. Looking at both your arguments, I agree with Harring that they amount to the same thing. But as he also said: "changing the mental mode for parsing" has a cost, and "We however are *not* starting from scratch. This shifts what we'll accept for costs/gains ratio." So any change "has to have significant gains for changing the existing form." The problem is that you're both thinking in terms of what the package mangler wants, and not in terms of how people think. When you try to build a package from source, the first thing you ask is "What libraries does it need?" Then "What tools do I need at build-time to compile it?" "How do I configure the package, and what's the effect in terms of functionality and dependencies if I tell it not to use specific libraries, which I might not have or want to download?" Then "What does it need on the host system to run it (given that I've already installed the libraries or it wouldn't have built)?" See how those map to simple variables and USE flags, that people are used to handling? That's why ports does it like that, and that's why the format was copied (in simplified form to ease implementation) for portage. The only shown advantage in your methods is a quicker cache format, which can be inferred from the existing syntax, and would thus never even hit user machines, if you just used it in the cache. And for that, you want to radically change the way everyone writes ebuilds, along with all the maintenance headaches, instead of adding a variable that plugs the gap in the original spec. Oh, and some putative ability to arbitrarily add new labels in the hypothetical future, all specified in terms of package manager internals. You're getting it wrong: those flow (and should be inferred) from the roles that the various dependencies play in the build process, not the other way round. Roles named by declarative variables, that match the mental model people have of the build process. That way your format supports its users in a transparent manner, instead of making them jump thru hoops and learn more and more obscure syntax, along with new, more complex, ways of doing the same thing you were doing before without the headache. Just agree a format, and use it in the cache, already. Or y'know, don't call it an ebuild. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
