1 |
On 14 September 2012 10:17, Brian Harring <ferringb@×××××.com> wrote: |
2 |
>> All you need is something in bash that can parse DEPENDENCIES and |
3 |
>> populate *DEPEND , and the underlying guts could be done in |
4 |
>> practically any language without requiring PM specific |
5 |
>> implementations. |
6 |
> |
7 |
> You've got it inverted; if any autopopulation is occuring, *DEPEND -> |
8 |
> DEPENDENCIES is the sane form. |
9 |
> |
10 |
> While it definitely *is* possible to render DEPENDENCIES down into |
11 |
> depend/rdepend (after all, the PM has to do exactly this for |
12 |
> resolution), that does /not/ mean doing it in bash is a good idea. |
13 |
> |
14 |
> I'd really not want to try that using labels; using use conditionals |
15 |
> ('dep:run,build? ( targets )') is frankly a bit easier imo, but still; |
16 |
> why do so unless one likes pain? It doesn't actually gain us |
17 |
> anything via missing the point of DEPENDENCIES. |
18 |
> |
19 |
> The point of unified DEPENDENCIES var (regardless of the form) is |
20 |
> thus: |
21 |
> 1) ability to specify common deps once, w/out having to use |
22 |
> intermediate vars/copy-pasting/etc. Think COMMON_DEPEND, and this |
23 |
> should make sense. |
24 |
> |
25 |
> 2) To shift to a form where adding new dependency targets is easy- |
26 |
> whether it be sdepend, fdepend, tdepend, or hdepend (or |
27 |
> ONE-RING-DEPEND to rule them all). This actually is rather important; |
28 |
> for the average 95% case, devs won't actually have to pay much |
29 |
> attention to those vars; but for those of us a bit further out (cross |
30 |
> compilation, heavy parallelization, etc) those depend forms are |
31 |
> becoming increasingly painful in their absense. |
32 |
> |
33 |
> |
34 |
> Basically, having devs specify DEPENDENCIES in ebuilds, which then an |
35 |
> eclass chunks out into DEPEND/RDEPEND misses the point of this; it's |
36 |
> doable, it's just not particularly sane imo. |
37 |
> |
38 |
> The other way around, having *DEPEND automatically be collapsed into |
39 |
> DEPENDENCIES, however is very sane- it makes transition/compatibilty |
40 |
> for devs bloody simple, while structuring it so we can do further |
41 |
> enhancements. |
42 |
> |
43 |
> ~harring |
44 |
> |
45 |
|
46 |
|
47 |
Sure, but at least this makes it a viable proof-of-concept without |
48 |
needing all the different PM's to implement the new spec first, and |
49 |
due to not being EAPI bound when done this way, means you can just do |
50 |
it and have it work both now and in the future. |
51 |
|
52 |
And because of this "experimental" nature, you don't have to do *ALL* |
53 |
the parsing in bash, you could make the eclass use some external code |
54 |
to parse it and spit it out, and simply have the eclass depend on that |
55 |
external program regardless. |
56 |
|
57 |
I agree that long term, a Unified DEPENDENCIES implementation is the |
58 |
way forward, but if you want to convince people, having something |
59 |
which has been demonstrated and tested in a real world setting goes a |
60 |
long way. |
61 |
|
62 |
-- |
63 |
Kent |
64 |
|
65 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
66 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
67 |
|
68 |
http://kent-fredric.fox.geek.nz |