| 1 |
Hi guys. |
| 2 |
|
| 3 |
I have some vars and code that is shared among gnatbuild.eclass, gnat.eclass |
| 4 |
and gnat.eselect module. Right now most of it is in the eselect module that |
| 5 |
gets sourced by gnat.eclass (after minor cleanup) with a var or two |
| 6 |
duplicated in gnatbuild.eclass. I would like to organize this a bit better, |
| 7 |
now that iternals have largerly stabilized. The trivial way would be to split |
| 8 |
common code off into some file and just source it where proper. I am asking |
| 9 |
in case there is some "advanced" or official way to do this. |
| 10 |
|
| 11 |
As for sourcing. The most straightforward way seems to be to provide |
| 12 |
another eclass - some gnat-common.eclass (or is there any naming policy? |
| 13 |
should it be gnat-functions.eclass then?) and then inherit it in |
| 14 |
gnatbuild.eclass and gnat.eclass and source it from eselect module. |
| 15 |
|
| 16 |
The good about with this approach is that it is guaranteed to be there for |
| 17 |
other eclasses to use and does not depend on the eselect module being |
| 18 |
installed. (Though, on the other hand, with everything-gnat depending on the |
| 19 |
module this may not be such a big deal). |
| 20 |
|
| 21 |
The bad is that, with it being an eclass one would expect the usual ability to |
| 22 |
override it by putting new version under PORTAGE_TMPDIR. While this would be |
| 23 |
handled naturally for the eclasses, this search and identify functionality |
| 24 |
will have to be added to the eselect module, which is at least boring :), but |
| 25 |
more seriously, this should be supported by eselect framework, not individual |
| 26 |
modules. |
| 27 |
|
| 28 |
Also, an eselect module can "inherit" some other eselect module, which is |
| 29 |
close but not quite the same. It searches for bash scripts |
| 30 |
under /usr/share/eselect/libs/, but putting there gnat specific stuff, |
| 31 |
really something that would be usefull mostly for ebuilds and eclasses, is |
| 32 |
not quite right. |
| 33 |
|
| 34 |
So, what could be considered to be a right way to have this common code |
| 35 |
separated? Can, perhaps, libs/package-manager.bash be expanded to provide |
| 36 |
function that would source an eclass (performing all the proper searching)? |
| 37 |
|
| 38 |
George |
| 39 |
-- |
| 40 |
gentoo-dev@g.o mailing list |
Archives