On Wed, Sep 05, 2012 at 12:06:45AM +0000, Jorge Manuel B. S. Vicetto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 31-08-2012 20:46, Ciaran McCreesh wrote:
>
> <snip>
>
> > Also, we're getting rather a lot of *DEPEND variables here... If
> > we're making people make major changes to their deps, which for
> > HDEPEND we definitely would be, then the "it's expensive since
> > people would have to redo their deps" argument against a combined
> > DEPENDENCIES variable goes out of the window, so we should rethink
> > that too.
>
> I have to agree with Ciaran, instead of multiplying DEPEND variables,
> it's probably time we move to a single DEPENDENCIES variable.
Personally, my complaints re: it are that 1) while minor, the
labels in some cases are overly verbose; recommendations instead of
recommends, suggestions instead of suggests, etc. 2) An actual
flaw in their design (imo): it tries to intermix two different
forms of parsing, without any real justification for *why* beyond
*hey look kids, I can!*; The two can intersect in slightly fucked
up ways, case in point:
DEPENDENCIES="
run+build:
cat/the
x? ( cat/cow
test:
y? ( cat/says
z? ( cat/moo
)))
Now, there may be some unstated rules that disallow that, but if that
*is* allowed, that's frankly dumb. As to if it's disallowed, it's
kind of a design flaw that the situation can occur requiring an
explicit suppression.
Rather than invent and try intermixing a secondary form, just using
the existing strikes me as saner; either we can have a specific
use_expand group like thus:
DEPENDENCIES="
dep_run? ( cat/monkeys )
dep_run+build? ( cat/foo )"
Or, preferable imo, do away w/ the +, use a more natural ',' for phase
separation, and use ':';
DEPENDENCIES="
dep:run? ( cat/monkeys )
dep:run,build? ( cat/foo )"
Doing it that way reuses the existing parsing infrastructure (good)
via just requiring a change to the use validation machinery (easy if
the PM is implemented sanely).
It also is able to express things that exheres variation can't do as
cleanly; considering build/fetch/post/run/test as the viable dep
targets:
DEPENDENCIES="
build+fetch+post+test:
some-dep"
vs
DEPENDENCIES="!dep:run? ( some-dep )"
I don't much expect that to occur, but the potential exists, thus
mentioning it.
One unstated fault re: DEPENDENCIES btw, is it will not play nice w/
exactly one of blocks. Treating '^^' as "exactly one of", consider:
DEPENDENCIES="
^^ (
run:
cat/blah
build:
cat/dar
cat/foon
)"
Is that a stupid dep? You bet your ass it is.. But it would have to
be explicitly suppressed by the parser for any such construct- moreso,
repoman would have to spot it which is slightly unfun.
Finally, one note; while certain folk have been making lots of noise
about DEPENDENCIES being the best thing since sliced bread, their
isn't much comment about how one actually transitions to it without
making eclass authors who have to support both pre-DEPENDENCIES, and
post-DEPENDENCIES eapis happy; kind of swiss cheeses the hell out of
the code frankly.
A compatibility hack that stacks them is strongly advisable; something
akin to the following:
Literally, we do the following:
inherit() {
if eapi blah; then
local DEPEND PDEPEND RDEPEND
<usual saving/protection of DEPENDENCIES var>
else
<usual saving/protection of DEPEND/PDEPEND/RDEPEND vars>
fi
<normal sourcing machinery>
if eapi blah; then
local _deps=( ) _x
for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do
[ -n "${!_x}" ] && deps+=( "${!_x}" )
done
[ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}"
unset DEPEND RDEPEND PDEPEND _x _deps
<normal stacking/restoration of DEPENDENCIES rules>
else
<normal stacking/restoration of RDEPEND/PDEPEND/DEPEND>
fi
}
Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set
the DEPENDENCIES directly; those that have to support multiple eapi's
(aka, every fricking eclass that exists right now) can just use the
old form, shifting into the new form as things progress.
Either way, the dual parsing required for exheres version I'm -1 on;
I'm generally wary of NIH modifications, but the form I've mentioned
that reuses our existing machinery is +.5...ish... from my standpoint
(+1 on the form, just kind of 'meh' on the single var angle despite
mostly agreeing w/ the reasoning).
Either way, on w/ the flaming/insinuations of
idiocy/counter-insinuations of being a wee bit too friendly w/
sheep...
~harring
