| 1 |
Ben de Groot posted on Wed, 19 Sep 2012 12:22:06 +0800 as excerpted: |
| 2 |
|
| 3 |
> On 16 September 2012 21:15, Brian Harring <ferringb@×××××.com> wrote: |
| 4 |
|
| 5 |
>> So... basically, people are already doing this manually with their own |
| 6 |
>> intermediate vars. |
| 7 |
> |
| 8 |
> And this works fine, so it doesn't warrant a cosmetic change. |
| 9 |
|
| 10 |
@ferringb: |
| 11 |
|
| 12 |
yngwin has a point that I've not seen addressed. |
| 13 |
|
| 14 |
What /is/ wrong with the whole CDEPEND intermediate var idea? It seems |
| 15 |
to work and /I/ don't know of any problems with it (and it would appear, |
| 16 |
neither does yngwin), yet you talk about it as if there's something wrong |
| 17 |
with it. |
| 18 |
|
| 19 |
And while we're at it, do DEPEND="$RDEPEND ..." style solutions have the |
| 20 |
same problems (or lack thereof)? |
| 21 |
|
| 22 |
FWIW I personally like the whole single-var idea, and CERTAINLY |
| 23 |
appreciate the various statistical cache savings, etc. If we were |
| 24 |
starting from scratch now, I'd definitely favor the single var approach. |
| 25 |
But the combined developer mental cost of having to learn the new method |
| 26 |
and then maintain a working understanding of both over some longer period |
| 27 |
is nothing to sneeze at, and I'm not entirely convinced that it's worth |
| 28 |
that cost, even assuming a doubling of the number of dependency types |
| 29 |
with a lot of commonality between them, and the added benefit a single |
| 30 |
deps var would have in that case. |
| 31 |
|
| 32 |
And the case for a single deps var isn't being helped by the implication |
| 33 |
that there's something wrong with both the intermediate var and copying |
| 34 |
var methods, without ever saying what that "wrong" might be, in the face |
| 35 |
of the experience of many that those existing methods "just work". So if |
| 36 |
there's something wrong with them, let's get it out there where people |
| 37 |
can see it. And if there isn't, please eliminate the noise of that |
| 38 |
implication from the argument. |
| 39 |
|
| 40 |
Thanks. =:^) |
| 41 |
|
| 42 |
-- |
| 43 |
Duncan - List replies preferred. No HTML msgs. |
| 44 |
"Every nonfree program has a lord, a master -- |
| 45 |
and if you use the program, he is your master." Richard Stallman |
Archives