On Mon, 19 Oct 2015 09:51:20 -0400 Rich Freeman <ri...@gentoo.org> wrote: [...] > > > >> I'd say the best approach for compatibility if you have an existing > >> eclass and it already exports src_prepare is to not call > >> eapply_user unless it firmly falls into the #2 category above. > > > > Replace 'not call eapply_user' by 'not export src_prepare' and I'd > > agree with you if going a bit further by ensuring there is no hidden > > problem: > > Well, taken together my recommendation does amount to: > 1. Avoid exporting src_prepare at all. > 2. If you do export src_prepare, then don't call eapply_user.
2. sucks: an ebuild inheriting that eclass will have to redefine src_prepare in order not to break with eapi6, so there's no point in exporting the function in the first place > That means that anybody creating an ebuild that uses an eclass which > does export src_prepare should define the phase in the ebuild, call > the various eclass src_prepares in the appropriate orders, and call > eapply_user in the appropriate place. Since the ebuild needs to be > modified to use EAPI6 it can be done at that time. basically killing EXPORT_FUNCTIONS, which is what I was discussing below. > > Going through each eclass exporting src_prepare and defining > > which should export it and which should not. I hope what you say is > > sufficient, but it'd be a bad idea to set this in stone for > > realizing in a few months that this forces people to write crappy > > code for having some eclasses to co-exist nicely. > > You already need to write crappy code to get some eclasses to co-exist > nicely, because they export conflicting phase functions assuming > they're the only eclass you'll use. no, believe me, defining phase functions and calling eclasses' ones in the right order is definitely not what I call crappy code :) [...] > > > > Some temptative list of which could be annoying (as in, do not seem > > to be 'do everything' eclasses): > > > > bzr.eclass > > -> patches (now useless) and bootstrap script, dropping it might > > encounter some resistance > > cuda.eclass > > -> appends cflags, could easily be moved to src_configure and > > not exported > > java-pkg-opt-2.eclass > > -> sanity checks & autofixing, not sure how to handle > > subversion.eclass > > -> patches (now useless) and bootstrap script, dropping it might > > encounter some resistance > > vala.eclass > > -> sets up some kind of virtual env, could very well be > > src_configure > > The solution to these kinds of problems isn't to remove functionality > from the eclass, but rather just export a function that ebuilds can > call from src_prepare at the appropriate time, rather than just trying > to do it all magically. Now I realize this wasn't clear: I'm not talking about removing functionality, but relegating those eclasses to the rank of 'must not export src_prepare'. With that in mind, I was considering the problem of having to write more boilerplate/duplicated code in eapi6 for its consumers, and somewhat ensuring the function has been called (for the java case). > This was discussed fairly extensively at: > http://article.gmane.org/gmane.linux.gentoo.devel/92581 > > I'm not attempting to tackle that now, but as a step in the right > direction I suggest that eclasses not try to call eapply_user in > general, and then we don't have to worry about the situation where you > want to use three eclasses which all try to call it. > > I think the long-term solution is to stop exporting phase functions in > eclasses. I'd recommend stripping the ability to do so at all from > PMS, except for the whole KDE exception which makes sense to me. The 'call eapply_user only once' problem is a lightweight version of this one, so should be easy to solve, and solved before considering more drastic options I think :) Also, since you seem to know well KDE: where would you call eapply_user, in kde eclasses or cmake-utils ? Alexis.
