Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 452880 - add an src_setup() phase for future EAPI
Summary: add an src_setup() phase for future EAPI
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL: http://archives.gentoo.org/gentoo-dev...
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2013-01-18 22:56 UTC by Sergei Trofimovich
Modified: 2019-10-23 08:41 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Trofimovich gentoo-dev 2013-01-18 22:56:30 UTC
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"
    }
Comment 1 Ciaran McCreesh 2013-01-18 22:59:56 UTC
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.
Comment 2 Ciaran McCreesh 2013-01-18 23:02:21 UTC
Also, we have MERGE_TYPE now...
Comment 3 Sergei Trofimovich gentoo-dev 2013-01-19 00:36:59 UTC
[ 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?
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-14 09:10:49 UTC
(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.
Comment 5 Sergei Trofimovich gentoo-dev 2013-07-27 20:23:05 UTC
Yeah, i guess MERGE_TYPE is fine.

Thanks!
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-10-23 08:41:15 UTC
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.