Gentoo Archives: gentoo-dev

From: Maciej Mrozowski <reavertm@××××××.fm>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] New eclass proposal: auto-export
Date: Wed, 03 Jun 2009 16:24:54
Message-Id: 200906031824.52183.reavertm@poczta.fm
In Reply to: [gentoo-dev] New eclass proposal: auto-export by "Petteri Räty"
1 On Wednesday 22 of April 2009 15:35:37 Petteri Räty wrote:
2 > Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
3 > of functions. This way all eclasses don't have to duplicate the EAPI
4 > detection code. If people find this useful, I will document it properly
5 > with eclass-manpages etc.
6
7 I like the idea, I'd have some feature request regarding it.
8
9 I'd like to have global eclass-wise EXPORT_FUNCTIONS variable introduced in
10 ebuilds (functions and variables can have identical names, bash handles it)
11 with list of allowed phases to export for all inherited eclasses.
12 It's needed in cases when eclass global scope is needed (for some setup for
13 example, setting SLOT etc) but overriding phases is not desired.
14 Currently it seems to be needed to override every not needed phase with dummy
15
16 phase_function() {
17 :
18 }
19
20 It means overriding all src_* phases if no ${S} is present.
21
22 With proposed solution, there would be for example:
23 in ebuild:
24
25 EXPORT_FUNCTIONS="pkg_setup pkg_postinst pkg_postrm"
26 inherit kde4-base
27 [...]
28
29 in eclasses there would be autoexport code
30
31 autoexport.eclass would need to be tweaked to export only those defined phases
32 that are listed in EXPORT_FUNCTIONS if EXPORT_FUNCTIONS is not empty
33 That would disable overriding not wanted phases all way down (provided all
34 eclasses all way down use autoexport that is).
35
36 --
37 regards
38 MM

Attachments

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