On Sat, Sep 15, 2012 at 11:06:01PM +1200, Kent Fredric wrote:
> On 14 September 2012 10:17, Brian Harring <ferri...@gmail.com> wrote:
> >> All you need is something in bash that can parse DEPENDENCIES and
> >> populate *DEPEND , and the underlying guts could be done in
> >> practically any language without requiring PM specific
> >> implementations.
> >
> > You've got it inverted; if any autopopulation is occuring, *DEPEND ->
> > DEPENDENCIES is the sane form.
> >
> > While it definitely *is* possible to render DEPENDENCIES down into
> > depend/rdepend (after all, the PM has to do exactly this for
> > resolution), that does /not/ mean doing it in bash is a good idea.
> >
> > I'd really not want to try that using labels; using use conditionals
> > ('dep:run,build? ( targets )') is frankly a bit easier imo, but still;
> > why do so unless one likes pain? It doesn't actually gain us
> > anything via missing the point of DEPENDENCIES.
> >
> > The point of unified DEPENDENCIES var (regardless of the form) is
> > thus:
> > 1) ability to specify common deps once, w/out having to use
> > intermediate vars/copy-pasting/etc. Think COMMON_DEPEND, and this
> > should make sense.
> >
> > 2) To shift to a form where adding new dependency targets is easy-
> > whether it be sdepend, fdepend, tdepend, or hdepend (or
> > ONE-RING-DEPEND to rule them all). This actually is rather important;
> > for the average 95% case, devs won't actually have to pay much
> > attention to those vars; but for those of us a bit further out (cross
> > compilation, heavy parallelization, etc) those depend forms are
> > becoming increasingly painful in their absense.
> >
> >
> > Basically, having devs specify DEPENDENCIES in ebuilds, which then an
> > eclass chunks out into DEPEND/RDEPEND misses the point of this; it's
> > doable, it's just not particularly sane imo.
> >
> > The other way around, having *DEPEND automatically be collapsed into
> > DEPENDENCIES, however is very sane- it makes transition/compatibilty
> > for devs bloody simple, while structuring it so we can do further
> > enhancements.
> >
> > ~harring
> >
>
>
> Sure, but at least this makes it a viable proof-of-concept without
> needing all the different PM's to implement the new spec first, and
> due to not being EAPI bound when done this way, means you can just do
> it and have it work both now and in the future.
>
> And because of this "experimental" nature, you don't have to do *ALL*
> the parsing in bash, you could make the eclass use some external code
> to parse it and spit it out, and simply have the eclass depend on that
> external program regardless.
>
> I agree that long term, a Unified DEPENDENCIES implementation is the
> way forward, but if you want to convince people, having something
> which has been demonstrated and tested in a real world setting goes a
> long way.
Honestly, QA would be well within their rights to kick anyone who did
this, *hard* in the shins.
I understand your notion- specifically proof of concept, show the
data, etc; I just think you've still got inverted, too focused on
trying to do it in bash.
To demonstrate the gain of this, we basically take the existing tree's
deps, and re-render it into a unified DEPENDENCIES form.
As for adding support to a PM, if we use the use conditional proposal
of mine, it's bloody simple- the PM already supports it, we just need
some minor USE_EXPAND adjustments.
~harring
