public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] where to put common stuff for eclasses and eselect modules?
@ 2007-09-11 10:41 George Shapovalov
  0 siblings, 0 replies; only message in thread
From: George Shapovalov @ 2007-09-11 10:41 UTC (permalink / raw
  To: gentoo-dev

Hi guys.

I have some vars and code that is shared among gnatbuild.eclass, gnat.eclass 
and gnat.eselect module. Right now most of it is in the eselect module that 
gets sourced by gnat.eclass (after minor cleanup) with a var or two 
duplicated in gnatbuild.eclass. I would like to organize this a bit better, 
now that iternals have largerly stabilized. The trivial way would be to split 
common code off into some file and just source it where proper. I am asking 
in case there is some "advanced" or official way to do this.

As for sourcing.  The most straightforward way seems to be to provide 
another eclass - some gnat-common.eclass (or is there any naming policy? 
should it be gnat-functions.eclass then?) and then inherit it in 
gnatbuild.eclass and gnat.eclass and source it from eselect module. 

The good about with this approach is that it is guaranteed to be there for 
other eclasses to use and does not depend on the eselect module being 
installed. (Though, on the other hand, with everything-gnat depending on the 
module this may not be such a big deal). 

The bad is that, with it being an eclass one would expect the usual ability to 
override it by putting new version under PORTAGE_TMPDIR. While this would be 
handled naturally for the eclasses, this search and identify functionality 
will have to be added to the eselect module, which is at least boring :), but 
more seriously, this should be supported by eselect framework, not individual 
modules. 

Also, an eselect module can "inherit" some other eselect module, which is 
close but not quite the same. It searches for bash scripts 
under  /usr/share/eselect/libs/, but putting there gnat specific stuff, 
really something that would be usefull mostly for ebuilds and eclasses, is 
not quite right.

So, what could be considered to be a right way to have this common code 
separated? Can, perhaps, libs/package-manager.bash be expanded to provide 
function that would source an eclass (performing all the proper searching)?

George
-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2007-09-11 10:50 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-11 10:41 [gentoo-dev] where to put common stuff for eclasses and eselect modules? George Shapovalov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox