* [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
@ 2009-03-06 20:57 Donnie Berkholz
2009-03-06 21:37 ` [gentoo-dev] " Christian Faulhammer
` (4 more replies)
0 siblings, 5 replies; 10+ messages in thread
From: Donnie Berkholz @ 2009-03-06 20:57 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1.1: Type: text/plain, Size: 1022 bytes --]
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?
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
[-- Attachment #1.2: x-modular.eclass.diff --]
[-- Type: text/plain, Size: 1638 bytes --]
--- /home/donnie/src/gentoo-x86/eclass/x-modular.eclass 2009-03-06 12:11:38.000000000 -0800
+++ x-modular.eclass 2009-03-06 12:16:25.000000000 -0800
@@ -26,6 +26,21 @@
# there. You may also want to change the SLOT.
XDIR="/usr"
+EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_preinst pkg_postinst pkg_postrm"
+
+case "${EAPI:-0}" in
+ 0|1)
+ ;;
+ 2)
+ EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare src_configure"
+ ;;
+ *)
+ die "Unknown EAPI ${EAPI}"
+ ;;
+esac
+
+EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
+
IUSE=""
HOMEPAGE="http://xorg.freedesktop.org/"
@@ -297,6 +312,15 @@
elibtoolize
}
+# @FUNCTION: x-modular_src_prepare
+# @USAGE:
+# @DESCRIPTION:
+# Prepare a package after unpacking, performing all X-related tasks.
+x-modular_src_prepare() {
+ x-modular_patch_source
+ x-modular_reconf_source
+}
+
# @FUNCTION: x-modular_src_unpack
# @USAGE:
# @DESCRIPTION:
@@ -306,8 +330,7 @@
x-modular_server_supports_drivers_check
x-modular_dri_check
x-modular_unpack_source
- x-modular_patch_source
- x-modular_reconf_source
+ has src_prepare ${EXPORTED_FUNCTIONS} || x-modular_src_prepare
}
# @FUNCTION: x-modular_font_configure
@@ -390,7 +413,7 @@
# @DESCRIPTION:
# Compile a package, performing all X-related tasks.
x-modular_src_compile() {
- x-modular_src_configure
+ has src_configure ${EXPORTED_FUNCTIONS} || x-modular_src_configure
x-modular_src_make
}
@@ -645,5 +668,3 @@
create_font_cache() {
font_pkg_postinst
}
-
-EXPORT_FUNCTIONS src_unpack src_compile src_install pkg_preinst pkg_postinst pkg_postrm
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* [gentoo-dev] Re: x-modular.eclass: A modified approach to EAPI support
2009-03-06 20:57 [gentoo-dev] x-modular.eclass: A modified approach to EAPI support Donnie Berkholz
@ 2009-03-06 21:37 ` Christian Faulhammer
2009-03-06 22:33 ` [gentoo-dev] " Petteri Räty
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Christian Faulhammer @ 2009-03-06 21:37 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
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/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
2009-03-06 20:57 [gentoo-dev] x-modular.eclass: A modified approach to EAPI support Donnie Berkholz
2009-03-06 21:37 ` [gentoo-dev] " Christian Faulhammer
@ 2009-03-06 22:33 ` Petteri Räty
2009-03-07 7:58 ` Rémi Cardona
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Petteri Räty @ 2009-03-06 22:33 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
2009-03-06 20:57 [gentoo-dev] x-modular.eclass: A modified approach to EAPI support Donnie Berkholz
2009-03-06 21:37 ` [gentoo-dev] " Christian Faulhammer
2009-03-06 22:33 ` [gentoo-dev] " Petteri Räty
@ 2009-03-07 7:58 ` Rémi Cardona
2009-03-07 9:50 ` Ulrich Mueller
2009-03-08 5:22 ` Donnie Berkholz
4 siblings, 0 replies; 10+ messages in thread
From: Rémi Cardona @ 2009-03-07 7:58 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
2009-03-06 20:57 [gentoo-dev] x-modular.eclass: A modified approach to EAPI support Donnie Berkholz
` (2 preceding siblings ...)
2009-03-07 7:58 ` Rémi Cardona
@ 2009-03-07 9:50 ` Ulrich Mueller
2009-03-07 10:06 ` Nirbheek Chauhan
2009-03-08 5:22 ` Donnie Berkholz
4 siblings, 1 reply; 10+ messages in thread
From: Ulrich Mueller @ 2009-03-07 9:50 UTC (permalink / raw
To: gentoo-dev
>>>>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
2009-03-07 9:50 ` Ulrich Mueller
@ 2009-03-07 10:06 ` Nirbheek Chauhan
2009-03-08 20:23 ` Alistair Bush
0 siblings, 1 reply; 10+ messages in thread
From: Nirbheek Chauhan @ 2009-03-07 10:06 UTC (permalink / raw
To: gentoo-dev
On Sat, Mar 7, 2009 at 3:20 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> 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?
>
If we get all Ciaran-ey about that, then we can't even assume the
existence of a case statement in some future version of bash (which is
required by some EAPI)
--
~Nirbheek Chauhan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
2009-03-06 20:57 [gentoo-dev] x-modular.eclass: A modified approach to EAPI support Donnie Berkholz
` (3 preceding siblings ...)
2009-03-07 9:50 ` Ulrich Mueller
@ 2009-03-08 5:22 ` Donnie Berkholz
2009-03-08 10:38 ` David Leverton
4 siblings, 1 reply; 10+ messages in thread
From: Donnie Berkholz @ 2009-03-08 5:22 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
On 12:57 Fri 06 Mar , 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.
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!
I ran a quick check across everything in the tree and was happy to see
nothing doing this besides my eclass patch. Here's the scriptlet I used:
for i in /usr/portage/eclass/*; do
grep -q EXPORT_FUNCTIONS $i || continue
grep -q inherit $i || continue
LINE1=$(grep -n EXPORT_FUNCTIONS $i | grep -v ':#' | cut -d: -f1 | head -n1)
LINE2=$(grep -n inherit $i | grep -v ':#' | cut -d: -f1 | tail -n1)
if [[ $LINE1 -lt $LINE2 ]]; then
echo $i $LINE1 $LINE2
fi
done
Manual checking of the two results showed false positives.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
2009-03-08 5:22 ` Donnie Berkholz
@ 2009-03-08 10:38 ` David Leverton
2009-03-08 22:38 ` Zac Medico
0 siblings, 1 reply; 10+ messages in thread
From: David Leverton @ 2009-03-08 10:38 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
2009-03-07 10:06 ` Nirbheek Chauhan
@ 2009-03-08 20:23 ` Alistair Bush
0 siblings, 0 replies; 10+ messages in thread
From: Alistair Bush @ 2009-03-08 20:23 UTC (permalink / raw
To: gentoo-dev
Nirbheek Chauhan wrote:
> On Sat, Mar 7, 2009 at 3:20 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>>> 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?
>>
>
> If we get all Ciaran-ey about that, then we can't even assume the
> existence of a case statement in some future version of bash (which is
> required by some EAPI)
>
>
I think in these cases we just have to use common sense. If a function
is deprecated or "known to be 'on the way out'" then using them would
obviously be a bad idea. On the other hand even if they are used,
surely someone would test an ebuild and discover this case pretty quickly.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
2009-03-08 10:38 ` David Leverton
@ 2009-03-08 22:38 ` Zac Medico
0 siblings, 0 replies; 10+ messages in thread
From: Zac Medico @ 2009-03-08 22:38 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-03-08 22:38 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-06 20:57 [gentoo-dev] x-modular.eclass: A modified approach to EAPI support Donnie Berkholz
2009-03-06 21:37 ` [gentoo-dev] " Christian Faulhammer
2009-03-06 22:33 ` [gentoo-dev] " Petteri Räty
2009-03-07 7:58 ` Rémi Cardona
2009-03-07 9:50 ` Ulrich Mueller
2009-03-07 10:06 ` Nirbheek Chauhan
2009-03-08 20:23 ` Alistair Bush
2009-03-08 5:22 ` Donnie Berkholz
2009-03-08 10:38 ` David Leverton
2009-03-08 22:38 ` Zac Medico
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox