It looks like there are enough funcs and vars that are "cross-inherited" among gnatbuild.eclass, gnat.eclass and eselect-gnat to warrant a common "root" eclass holding these items, perhaps calling it gnat_common.eclass. The shared parameters as of now (shared via ugly hack of adjusting/sourcing another eclass or module, some by duplicating var defines): 1. CONFIG_PATH in gnatbuild.eclass and SPECSDIR in gnat.eselect are the same items, should be joined. 2. check for MARKER and ENVDIR duplication 3. get_current_gnat is pulled into gnatbuild.eclass from gnat.eselect by sourcing. Likely will go away actually. 4. do_set is pulled from gnat.eselect into gnat.eclass. But can this be removed from gnat.eselect? 5. SPECSDIR is used in gnat.eclass Well, so far common vars are the principal candidates. 3. will probably go away soon and 4 may not be transferable. In this case sourcing of gnat.eselect by gnat.eclass will not be avoidable and then only the vars could be moved, which may not warrant a whole another eclass. Will have to think more about this whole issue. George
Looks like for implementing proper unmerge cleanup logic I will need to move the unset function form gnat.eselect to common eclass too. So, I'll need to seriously look into doing this. Perhaps most of the eselect functionality will have to be moved to the common eclass and then the eselect module itself would be very simple. George
Ok, 90% done. As per discussion with ciaranm in #192505 (why is that when I ask anything on -dev nobody answers? :)) the common code cannot reside in eclass nor anywhere in portage, as eselect module (or, for that matter, any other package not directly dealing with portage tree) cannot depend on portage tree being present. Nor would I accept duplication of code. The solution then is to have the core functions in a separate file belonging to eselect-gnat, (pure bash, no portage or eselect extensions). Everything gnat related depends on eselect-gnat directly or indirectly, therefore it can depend on this file being present at proper time. However it is better not to source that file at top level in any eclass (but this is Ok from within the eselect module). Location of this code: It only makes sence that it would go under /usr/share/gnat, I opted for keeping it inside the lib/ subdir, as this seems to make sense at the moment. Thus it became /usr/share/gnat/lib/gnat-common.bash. I was somewhat hesitant whether this should be under /usr/share or, actually, /usr/lib (which seems to make a bit more sense), but went with the first one, since eselect and all its extra modules put all the scripts under /usr/share. Just need to check what was that comment on the unset function about and then I should be able to close this bug. George
Actually this should block that reorg tracker..
