Dnia 2013-08-31, o godz. 01:17:26 Markos Chandras <hwoar...@gentoo.org> napisał(a):
> On 31 August 2013 00:37, Michał Górny <mgo...@gentoo.org> wrote:
> > Hello, all.
> >
> > After a few days of thinking, discovering and working, here it is.
> > The first working draft of new git eclass codenamed 'git-r3'.
> >
> > First of all, the name is not final. I'm open to ideas. I'm open to
> > naming it 'git-r1' to put it in line with my other -r1 eclasses :).
> > I'd definitely like to avoid 'git-3' though, since that version-like
> > naming was a mistake as almost-'python-2' eclass shown.
> >
> > Secondly, it's not even final that there will be a new eclass. Most
> > likely I will commit it as a new eclass since that way is easier for us
> > but if you prefer I may try to get it and git-2 more API-friendly
> > and work on making it a almost-drop-in replacement. Since, after all,
> > internals have actually changed much more than the API.
> >
>
> Hi,
>
> I have no capacity to review the eclass right now (although I promise
> I will soon)
> but I was wondering why the whole eclass is inside the " if [[ !
> ${_GIT_R3} ]] " block.
> Is it so you can avoid inheriting the same eclass twice? I haven't
> seen that before
> so I was wondering if that's the only reason. If yes, then maybe this
> needs to be solved in PM scope instead?
> As in, prevent portage from inheriting the same eclass twice instead
> of handling this case in the eclass itself.
Yep, it's exactly that. All my new eclasses use that, and vapier's use
rather some 'spank' serpentines. Plus mine have 'EXPORT_FUNCTIONS' out
of it, so wrapping them does not change export order.
I suggested that into EAPI [1] but it didn't get in so far. The issue
is that some eclasses may actually need to be sourced twice, e.g. due
to environment changing. Though they are nowhere near 'sane' then.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=422533
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
