Gentoo Archives: gentoo-dev

From: Maciej Mrozowski <reavertm@××××××.fm>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses
Date: Thu, 24 Sep 2009 01:39:32
Message-Id: 200909240339.27356.reavertm@poczta.fm
1 In pre-EAPI-2, src_unpack phase was the most logical phase to be provided by
2 SCM eclasses, thus classes has been set up to export ${ECLASS}_src_unpack.
3
4 This phase in most (if not all) SCM eclasses provided:
5 - unpack functionality - fetch and store in ${DISTDIR}
6 - bootstrap functionality - either patching or bootstrapping just unpacked
7 sourced with command
8
9 In EAPI-2, bootstrap functionality belongs to prepare phase, thus it's been
10 moved there - SCM eclasses in EAPI-2 codepath has been set up to provide
11 src_prepare.
12
13 And this is the problem (some people may be even unaware of it).
14 In pre EAPI-2 it was sufficient to do the following in live ebuilds:
15
16 inherit ${some_eclass} ${scm_eclass}
17
18 ${scm_eclass} inherited as last one, would just shadow src_unpack, providing
19 what we want. In EAPI-2 however, it as well shadows src_prepare which is in
20 *most* cases unwelcome, especially if one uses autopatcher (base.eclass, so
21 cmake-utils.eclass, kde4-*.eclass, and probably some other).
22
23 Because SCM bootstrap is either not used at all, or used very rarely, there's
24 suggestion to:
25 - either drop it
26 - or (preferably) to make SCM eclasses export src_prepare only on specific
27 request
28 - or to make it easier - to not export it at all - thus making it required for
29 developer to intentionally invoke ${ECLASS}_src_prepare if bootstrapping is
30 required.
31
32 --
33 regards
34 MM

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies