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
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