William Hubbs:
> All,
>
> I spoke with mgorny on IRC and found out what his concerns are about our
> current eclasses.
>
> First, he thinks we should get rid of base.eclass.
>
> I know there is work going on to get rid of it, but I haven't really
> looked into the status much yet. I do agree though, we shouldn't have a
> general-purpose eclass like this that overrides default phase functions.
> Things like this belong in PMS; not in an eclass.
>
> The other concern he mentioned was indirectly inherited eclasses being
> able to override phase functions.
>
> He said for example that if an ebuild inherits foo and foo inherits bar,
> foo should export all of the phase functions bar exports.
>
> This may cause some boilerplating in some of the eclasses, so I'm
> wondering if it would be feasible to make EXPORT_FUNCTIONS work only for
> the first level of inheritance?
>
> Thoughts?
I think the first thing to do and which already happened with e.g.
qmake-utils.eclass is to make a very strong distinction between utility
eclasses and those that export phase functions.
And yeah, disabling indirect exports would at worst cause some minor
boilerplating in eclasses (as in... you have to actually call
foo_src_compile() { base_src_compile ; } AND export it) instead of
ebuilds. That's reasonable IMO and makes them more readable and predictable.
In addition, we should probably fix the manpage format of the eclasses
with an explicit section about exported functions, so you don't have to
search for that info manually.
