| Summary: | [Future EAPI] kill off need for EXPORT_FUNCTIONS | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | SpanKY <vapier> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | esigra, mgorny |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
| Attachments: | export.log | ||
|
Description
SpanKY
2006-02-27 22:31:01 UTC
Created attachment 80879 [details]
export.log
irc conversation
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? (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. *** Bug 174412 has been marked as a duplicate of this bug. *** 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. 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. This is going nowhere since more then a decade. Closing per comment #5 and comment #6. |
