|Summary:||[Future EAPI] kill off need for EXPORT_FUNCTIONS|
|Product:||Gentoo Hosted Projects||Reporter:||SpanKY <vapier>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description SpanKY 2006-02-27 22:31:01 UTC
per our discussion on irc
Comment 1 SpanKY 2006-02-27 22:33:07 UTC
Created attachment 80879 [details] export.log irc conversation
Comment 2 Michał Górny 2013-02-15 21:48:16 UTC
So, what about phase functions which are exported optionally? Will we have to have them declared with two different names so that they don't get exported and at the same time are available to user?
Comment 3 SpanKY 2013-02-18 22:30:10 UTC
(In reply to comment #2) that is very much the exception, not the rule. should be trivial to have it *default* to exporting everything automatically found, but if the eclass has an explicit EXPORT_FUNCTIONS call, we use that instead.
Comment 4 Michał Górny 2013-03-14 09:22:58 UTC
*** Bug 174412 has been marked as a duplicate of this bug. ***
Comment 5 Ulrich Müller 2017-09-09 16:07:16 UTC
What would be the transition plan for this? Eclasses would still have to call EXPORT_FUNCTIONS for EAPIs 0 to 6. So the eclass would need a conditional for this, or it would still explicitly call EXPORT_FUNCTIONS also in later EAPIs. That would mean increased complexity for at least some years to come (until the last EAPI 6 ebuild is gone ...). Not sure if the relatively small gain of saving one line per eclass is worth it. Given that there also is no progress since more than a decade, I am inclined to close this bug as WONTFIX.
Comment 6 Michał Górny 2017-09-09 17:57:47 UTC
Furthermore, given that this doesn't really solve any problem, I seriously doubt implementing it is really worth the effort. Not to mention the unavoidable confusion.