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. |