Hi,

Donnie Berkholz <dberkholz@gentoo.org>:
> Any thoughts?

Nice is the centralisation of the EAPI check although I also like to
see function execution by EAPI on the spot. What I don't like is dying
on an unknown EAPI. Is it in the range of possibilities that the
provided phases will change drastically with EAPI > 2?

V-Li


--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

Donnie Berkholz wrote:
> I decided to try something a little different because I had some ideas
> for improving the existing EAPI patches I've seen going into other
> eclasses. So here is my patch for x-modular.eclass. I tested it with
> ebuilds using EAPIs 0, 1, and 2, and it appeared to work fine. It
> already happened to have a function called src_configure, so that
> doesn't appear in the patch.
>
> One thing I see as an improvement is a lack of EAPI value checks
> throughout the ebuild to avoid repetition between the function export
> and the function call. Things just check whether a function was
> exported, which is the only place where EAPI value checks happen.
>
> Additionally, the fallback in case statements is "I don't know what to
> do" and supported EAPIs are explicitly defined. This will make it
> obvious when the eclass doesn't support a new EAPI instead of it
> randomly failing after you try it.
>
> Any thoughts?
>
>

The other option instead of die would be DEPEND="THIS-IS-NOT-VALID".

Regards,
Petteri

Le 06/03/2009 21:57, Donnie Berkholz a écrit :

Any thoughts?


Looks pretty good to me. I don't have much else to say

Cheers,

Rémi

>>>>> On Fri, 06 Mar 2009, Donnie Berkholz wrote:

> Any thoughts?

> + *)
> + die "Unknown EAPI ${EAPI}"
> + ;;

Is is safe to assume that an unknown EAPI will provide a "die"
function?

Ulrich

On Sunday 08 March 2009 05:22:03 Donnie Berkholz wrote:
> FYI, using EXPORT_FUNCTIONS before inherit, as this patch caused
> x-modular.eclass to do, is broken in current portage releases. Zac said
> he would change this to be consistent with the lack of any ordering
> restriction in the PMS. Thanks to Tomáš Chvátal for tracking down this
> tricky bug!

Better to ask for PMS to be clarified. All existing package managers do
EXPORT_FUNCTIONS in more or less the same way, so changing it shouldn't
happen without an EAPI bump.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Leverton wrote:
> On Sunday 08 March 2009 05:22:03 Donnie Berkholz wrote:
>> FYI, using EXPORT_FUNCTIONS before inherit, as this patch caused
>> x-modular.eclass to do, is broken in current portage releases. Zac said
>> he would change this to be consistent with the lack of any ordering
>> restriction in the PMS. Thanks to Tomáš Chvátal for tracking down this
>> tricky bug!
>
> Better to ask for PMS to be clarified. All existing package managers do
> EXPORT_FUNCTIONS in more or less the same way, so changing it shouldn't
> happen without an EAPI bump.

As discussed on irc, if we make it conditional on EAPI then you'll
practically never be able to call EXPORT_FUNCTIONS before inherit
since eclasses generally support multiple EAPIs. So, I've added a
warning message that is triggered when EXPORT_FUNCTIONS is called
before inherit. In a year or two we can consider having the warning
removed.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkm0SPsACgkQ/ejvha5XGaN/+ACgsS44TWTR2fODGzwSI0XH5xN7
xpkAoOJhSWeXQDnhO8OuoXuViB2MNe7F
=RJI6
-----END PGP SIGNATURE-----