Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: eclass issues
Date: Mon, 18 Aug 2014 12:12:46
Message-Id: 53F1EDAF.1030205@gentoo.org
In Reply to: [gentoo-dev] rfc: eclass issues by William Hubbs
1 William Hubbs:
2 > All,
3 >
4 > I spoke with mgorny on IRC and found out what his concerns are about our
5 > current eclasses.
6 >
7 > First, he thinks we should get rid of base.eclass.
8 >
9 > I know there is work going on to get rid of it, but I haven't really
10 > looked into the status much yet. I do agree though, we shouldn't have a
11 > general-purpose eclass like this that overrides default phase functions.
12 > Things like this belong in PMS; not in an eclass.
13 >
14 > The other concern he mentioned was indirectly inherited eclasses being
15 > able to override phase functions.
16 >
17 > He said for example that if an ebuild inherits foo and foo inherits bar,
18 > foo should export all of the phase functions bar exports.
19 >
20 > This may cause some boilerplating in some of the eclasses, so I'm
21 > wondering if it would be feasible to make EXPORT_FUNCTIONS work only for
22 > the first level of inheritance?
23 >
24 > Thoughts?
25
26 I think the first thing to do and which already happened with e.g.
27 qmake-utils.eclass is to make a very strong distinction between utility
28 eclasses and those that export phase functions.
29
30 And yeah, disabling indirect exports would at worst cause some minor
31 boilerplating in eclasses (as in... you have to actually call
32 foo_src_compile() { base_src_compile ; } AND export it) instead of
33 ebuilds. That's reasonable IMO and makes them more readable and predictable.
34
35 In addition, we should probably fix the manpage format of the eclasses
36 with an explicit section about exported functions, so you don't have to
37 search for that info manually.

Replies

Subject Author
Re: [gentoo-dev] rfc: eclass issues Rich Freeman <rich0@g.o>