I often see one of two patterns: Pattern A) Code Before `inherit` to drive behaviour
Example A.1 SOME_VALUE="Foo" inherit someclass OTHERVALUE=Bar" inherit someotherclass This is used heavily in things using perl-module.eclass Pattern B) Require either function calls or have a finalising function call to apply settings. Example B.1 inherit someclass SOME_VALUE="Foo" SOME_OTHER_VALUE="Bar" someclass_post_src; Example B.2 inherit someclass someclass_set_some_value "Foo" someclass_set_some_other_value "Foo" Examples A.1 and B.1 essentially share the same logic: define a value, can call some function that augments that value into other values ( and in the case of A.1, the function is called "inherit" ) A.1 is the least-worst here, its just ugly and you have to remember to put the inherit *after* the variable or the variable will behave as if it wasn't there. And B.1 has the convenient defect that if you forget to call the finalising function at the end, the ebuild may be radically different. B.2 Seems to make things much more complicated for eclass authors. << TO THE POINT >> What I keep wanting to have is a hook that triggers after the ebuild is loaded, defined in the eclass. > source Foo.ebuild >> see inhert bar >> source bar.eclass >>> bar.eclass registers a hook bar_mauve >>> returns to processing Foo.ebuild >> Process code in Foo.ebuild > return to eclass handeler > trigger bar_mauve Note I've conveniently called it "bar_mauve" here because I have no idea what a good name will be, and establishing if the concept is useful or not should be done before we decide what we'll call it. The hook should be able to see and modify any variables that are to be expected visible to the ebuild itself, and the primary expected use would be augmenting exported variables based on other variables, like we presently do during ebuild sourcing in perl-module.eclass ( which is mostly computing SRC_URI from other variables ), essentially making it easier to write variable declaration based ebuilds. -- Kent
