Re: [gentoo-dev] EAPI placement

[Doug Klima]

Marius Mauch wrote:
> On Tue, 11 Dec 2007 16:59:28 -0500
> Doug Klima <cardoe@g.o> wrote:
>
>> Since it doesn't appear the question was answered by the last thread.
>> I'm starting a new thread.
>
> The only sane solution I can think of is that eclasses shouldn't be
> allowed to change EAPI, but use conditionals to behave differently if
> needed. Mixing two (or more) different arbitrary EAPIs isn't going to
> work as after the inital parsing package managers will only see the
> last EAPI value anyway. Also there is no guarantee that future EAPI
> versions will be backwards compatible, so if eclasses could have an
> EAPI version it would eventually require that all packages using it
> need the same EAPI version (similar for nested inheritance).
>
> It's trivial to let inherit check that an eclass doesn't modify EAPI,
> and adding the conditional code to eclasses isn't difficult either:
>
> foo.eclass:
>
> if [ -z "$EAPI" ]; then
>     inherit foo-eapi0
> fi
> case "$EAPI" in
>     0)
>         inherit foo-eapi0
>         ;;
>     1|2)
>         inherit foo-eapi1_2
>         ;;
>     *)
>         eerror "foo.eclass: unsupported EAPI value $EAPI"
>         ;;
> esac
>
> # EAPI independent code here
>
> Obviously instead of specific eclasses one could also inline the
> relevant code. The only two issues I see in this concept are the
> eventual multiplication of eclasses and the lack of proper error
> handling for unsupported EAPIs.
>
> Marius
>
> PS: Yes, this idea has been mentioned in the old thread as well
>

This again leads to in a sense, code duplication due to the fact that 
you have to have several different versions of the code for each EAPI. 
When you could simply have $pkg_manager execute an eclass as 1 EAPI, 
another eclass as another and the ebuild as a third EAPI and simplify it 
for the eclass maintenance.

-- 
Doug Klima <cardoe@g.o>
http://dev.gentoo.org/~cardoe/
-- 
gentoo-dev@g.o mailing list