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.
--
Kent
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
http://kent-fredric.fox.geek.nz
