Right way to inherit multiple eclasses

[Tim Zwiebel]

What's the right way to inherit multiple eclasses in an ebuild? From the documentation, it seems that "if multiple eclasses export the same function, the latest (inherited last) defined version wins".

I'd expect this to cause a problem if, for example, I inherit both foo and bar in my ebuild and both foo and bar use EXPORT_FUNCTIONS to export src_compile and src_install. I could also make things more complicated by wanting to do something extra in each of those steps.

Sure, I could define my own src_compile and src_install and manually call foo_src_compile and bar_src_compile. But that means that any time I import an eclass, I have to look through each of the inherited eclasses and write my own functions for each of the ones that they export. Is there a better way?

Thanks,

-Tim Zwiebel

[Mike Frysinger]

yes, this is how eclasses work, and yes, that's how you'd find out if you had a conflict.

for the bigger/common eclasses, the exported API generally doesn't change.  if they did, usually the eclass rev would be bumped (note how there are sometimes foo-r1 and foo-r2 eclasses).  that way existing users wouldn't break, and then people could slowly migrate to the newer version on a package-by-package basis that'd see testing during the update.

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Tim Zwiebel]

Thanks. I've noticed the -r1 convention. I guess I'll continue looking through each build step to ensure that any/all conflicts are handled. Luckily I shouldn't need to edit ebuild files all that often.

-Tim Zwiebel