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

[Ciaran McCreesh]

On Fri, 31 Aug 2012 13:03:00 -0700
Zac Medico <zmedico@g.o> wrote:
> For those who may not know, chromium-os currently uses a
> hard-host-depends ebuild as a workaround for our lack of HDEPEND
> support [1]. We could easily add HDEPEND in EAPI 5 if we want, since
> we already have a Portage patch attached to bug #317337 [2]. Here is
> a summary of what that Portage patch will do:
>
> In EAPI 5 or later, DEPEND has been divided into two parts:
> DEPEND for build-time target dependencies, and HDEPEND for
> build-time host dependencies. This division is designed
> specifically to minimize difficulty in the process of
> adapting ebuilds that were written for earlier EAPIs,
> and therefore it also minimizes the adjustments that
> ebuild developers will have to make to the thought
> processes involved when writing ebuilds from scratch. In
> an environment that does not involve cross-compilation,
> HDEPEND behaves the same as DEPEND. When an ebuild is
> converted from EAPI 4 or earlier to EAPI 5 or later,
> in order to support cross-compilation environments, some
> dependencies may need to be migrated to HDEPEND.
>
> For ebuilds that have EAPI 5 or later, the emerge
> --root-deps option has no effect since it is made obsolete
> by division between DEPEND and HDEPEND. If EAPI 4 or
> earlier ebuilds are used in combination with EAPI 5 or
> later ebuilds, the --root-deps behavior will still be
> applied to the EAPI 4 or earlier ebuilds (there is no
> behavior change for ebuilds having older EAPIs).

What exactly would the rules be for handling a package that is in both
DEPEND and HDEPEND, when ROOT is in effect? Would the versions be
expected to match? What about use flags?

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.

-- 
Ciaran McCreesh