Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?

[Brian Harring]

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