| Summary: | add an src_setup() phase for future EAPI | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Sergei Trofimovich (RETIRED) <slyfox> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | esigra, mgorny, pacho, ssuominen |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://archives.gentoo.org/gentoo-dev/msg_37999d6dc7840b4c40beb55435ea7d45.xml | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
We can't call it that, since various places exclude the src_ or pkg_ prefix, and they'll probably go horribly wrong if there are ambiguous names. Also, we have MERGE_TYPE now... [ CCed Samuli as he is expected to be one of big users of it ] (In reply to comment #1) > We can't call it that, since various places exclude the src_ or pkg_ prefix, > and they'll probably go horribly wrong if there are ambiguous names. Oh, that sounds bad. 'setup' and 'config' are nice words for it. Maybe src_setenv(), src_init_env() or src_prepare_env() then. (In reply to comment #2) > Also, we have MERGE_TYPE now... What is wrong with it? Is it unsafe to call it in exactly the same cases as src_unpack()/src_prepare() for $EAPI_with_$SUBJ and don't call otherwise? (In reply to comment #3) > [ CCed Samuli as he is expected to be one of big users of it ] > > (In reply to comment #1) > > We can't call it that, since various places exclude the src_ or pkg_ prefix, > > and they'll probably go horribly wrong if there are ambiguous names. > > Oh, that sounds bad. 'setup' and 'config' are nice words for it. > > Maybe src_setenv(), src_init_env() or src_prepare_env() then. Please don't. That would be terribly hard to recall right. > (In reply to comment #2) > > Also, we have MERGE_TYPE now... > > What is wrong with it? > > Is it unsafe to call it in exactly the same cases > as src_unpack()/src_prepare() for $EAPI_with_$SUBJ and don't call otherwise? I think he meant that you could do: pkg_setup() { if [[ $MERGE_TYPE == source]; then ... fi } IMO, if we were to add src_setup(), it would have to be exclusive to pkg_setup(). Algo like this: 1. if MERGE_TYPE == source and src_setup is defined, call src_setup. 2. otherwise, call pkg_setup. Having only one of the two called would probably avoid most of the problems with stripped phases in the scope of PMS. It would still require checking and fixing PMs that rely on that, though. Anyway, do you still want that (considering MERGE_TYPE)? If not, please close the bug. Yeah, i guess MERGE_TYPE is fine. Thanks! Hm, one argument for having src_setup XOR pkg_setup in ebuilds: right now pkg_setup() is always called for binpkgs. This means Portage needs to fetch binpkgs early in order to run it. However, many of them don't do anything because of MERGE_TYPE. Having an explicit choice of src_setup() vs pkg_setup() would make it possible to trivially elide src_setup() calls when installing from binary packages. On the cons side, it would involve non-trivial interactions between eclasses and ebuilds defining a different variant. |
I suggest adding src_setup() as a first of src_* phases intended to setup environment variables/check environment. Would be nice to have only ${T} available. Usage examples: Current dev-libs/nss/nss-3.14.ebuild (yes, function is not used, but defined) src_setup() { export LC_ALL="C" } Things which disable parallel building, set compiler, other environment: src_setup() { MAKEOPTS+=" -j1" tc-export... export HOME=${T}/there } Things which check tools sanity: src_setup() { echo "use gmp code" >${T}/gmp-link-test.c ${CTARGET}-gcc ${T}/gmp-test.c -lgmp -o ${T}/gmp-link-test.elf || die "please install gmp to your cross ${ROOT} environment" }