[gentoo-dev] New eclass proposal: auto-export

[gentoo-dev] New eclass proposal: auto-export

[Petteri Räty]

[-- Attachment #1.1: Type: text/plain, Size: 263 bytes --]

Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
of functions. This way all eclasses don't have to duplicate the EAPI
detection code. If people find this useful, I will document it properly
with eclass-manpages etc.

Regards,
Petteri

[-- Attachment #1.2: auto-export.eclass --]
[-- Type: text/plain, Size: 936 bytes --]

# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Original Author: Petteri Räty <betelgeuse@gentoo.org>
# Purpose: Automatically export functions.
#

EAPI_FUNCTIONS=(
	[0]="
	pkg_setup
	src_unpack
	src_compile
	src_install
	pkg_prerm
	pkg_postrm
	pkg_preinst
	pkg_postinst
	"
	[1]=""
	[2]="
	src_prepare
	src_configure
	"
)

#function has() {
#	true
#}

has ${EAPI:-0} ${!EAPI_FUNCTIONS[@]} || DEPEND="UNKNOWN_EAPI"

func-exists() {
	declare -F ${1} > /dev/null
}

auto-export() {
	local result=''
	for eapi in ${!EAPI_FUNCTIONS[@]}; do
		for func in ${EAPI_FUNCTIONS[${eapi}]}; do
			func-exists ${ECLASS}_${func} && result="${result} ${func}"
		done

		[[ ${eapi} == ${EAPI:-0} ]] && break
	done

	echo "exporting ${result}"
	EXPORT_FUNCTIONS ${result}
}

#function EXPORT_FUNCTIONS() {
#	echo "${@}"
#}

#ECLASS="foo"
#foo_src_unpack() { :; }

#auto-export

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] New eclass proposal: auto-export

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Petteri Räty wrote:
> Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
> of functions. This way all eclasses don't have to duplicate the EAPI
> detection code. If people find this useful, I will document it properly
> with eclass-manpages etc.
> 
> Regards,
> Petteri
> 

No need to tell me that the list for EAPI 0 is missing some functions. I
fixed that already.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] New eclass proposal: auto-export

[Arun Raghavan]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On Wed, 2009-04-22 at 16:35 +0300, Petteri Räty wrote:
> Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
> of functions. This way all eclasses don't have to duplicate the EAPI
> detection code. If people find this useful, I will document it properly
> with eclass-manpages etc.

Looks like a nice way to avoid silly errors while writing eclasses.
Would this make sense as a package manager feature?

-- Arun

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] New eclass proposal: auto-export

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

Arun Raghavan wrote:
> On Wed, 2009-04-22 at 16:35 +0300, Petteri Räty wrote:
>> Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
>> of functions. This way all eclasses don't have to duplicate the EAPI
>> detection code. If people find this useful, I will document it properly
>> with eclass-manpages etc.
> 
> Looks like a nice way to avoid silly errors while writing eclasses.
> Would this make sense as a package manager feature?
> 
> -- Arun

In general I would like to see more bash code shared between package
managers. For this case you would still have to keep code around for
current EAPIs. I think this feature has been on the table for new EAPI
features at least at some point.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] New eclass proposal: auto-export

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Wed, Apr 22, 2009 at 04:35:37PM +0300, Petteri R??ty wrote:
> Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
> of functions. This way all eclasses don't have to duplicate the EAPI
> detection code. If people find this useful, I will document it properly
> with eclass-manpages etc.

Mind you I follow the "Keep It Simple Stupid", but is this really 
needed?  In other words, how often do people really hit this?

If it's useful, whatever, but I can see the inverse of the problem 
you're trying to solve occuring- folks being told to use autoexport, 
then wondering how to block something from being exported...

Neutral towards it, just seems a bit much imo.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] New eclass proposal: auto-export

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

Brian Harring wrote:
> On Wed, Apr 22, 2009 at 04:35:37PM +0300, Petteri R??ty wrote:
>> Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
>> of functions. This way all eclasses don't have to duplicate the EAPI
>> detection code. If people find this useful, I will document it properly
>> with eclass-manpages etc.
> 
> Mind you I follow the "Keep It Simple Stupid", but is this really 
> needed?  In other words, how often do people really hit this?
> 
> If it's useful, whatever, but I can see the inverse of the problem 
> you're trying to solve occuring- folks being told to use autoexport, 
> then wondering how to block something from being exported...
> 
> Neutral towards it, just seems a bit much imo.
> ~harring

betelgeuse@pena ~ $ grep -l src_prepare /usr/portage/eclass/*.eclass | wc -l
19



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] New eclass proposal: auto-export

[Maciej Mrozowski]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

On Wednesday 22 of April 2009 15:35:37 Petteri Räty wrote:
> Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
> of functions. This way all eclasses don't have to duplicate the EAPI
> detection code. If people find this useful, I will document it properly
> with eclass-manpages etc.

I like the idea, I'd have some feature request regarding it.

I'd like to have global eclass-wise EXPORT_FUNCTIONS variable introduced in 
ebuilds (functions and variables can have identical names, bash handles it) 
with list of allowed phases to export for all inherited eclasses.
It's needed in cases when eclass global scope is needed (for some setup for 
example, setting SLOT etc) but overriding phases is not desired.
Currently it seems to be needed to override every not needed phase with dummy

phase_function() {
	:
}

It means overriding all src_* phases if no ${S} is present.

With proposed solution, there would be for example:
in ebuild:

EXPORT_FUNCTIONS="pkg_setup pkg_postinst pkg_postrm"
inherit kde4-base
[...]

in eclasses there would be autoexport code

autoexport.eclass would need to be tweaked to export only those defined phases 
that are listed in EXPORT_FUNCTIONS if EXPORT_FUNCTIONS is not empty
That would disable overriding not wanted phases all way down (provided all 
eclasses all way down use autoexport that is).

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]