[gentoo-dev] RFC: eblits.eclass

[gentoo-dev] RFC: eblits.eclass

[Matti Bickel]

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

Hi folks,

this is my first eclass proposal, so rip it apart gently ;)

Disclaimer: the work proposed is NOT my own, but rather contributed by
vapier (see [1] or sys-libs/glibc) and kumba (see [2] or
sys-kernel/mips-sources).

I propose to add eblits.eclass[2] (attached to this message) with the
purpose and author comments from [1].

A quick grep showed that glibc and mips-sources currently use functions
defined in global scope in each ebuild to do the job. The referenced
overlays also use eblits to install php-5.3 and this is currently
blocking php-5.3 from entering the tree.

sys-kernel/mips-sources also has comment:
# They'll likely be superseded someday by better ideas, possibly elibs.

That's why I titled this email "RFC" - I realize this eclass might be
obsolete in a not to distant future and possibly cause funny behaviour
in ebuilds that I'm not aware of.

So please enlighten me of any problems you can think of that adding
eblits.eclass as proposed above would cause. I'd be more than happy if
we can get an update on elibs progress, too.

As the need for such an eclass is very real (we really, really want
php-5.3 in the tree!), I want to limit discussion to one week, ending
April 18th. If there are no objections, I'll add the eclass after that date.

TIA, Matti

[1]
http://hg.hoffie.info/gentoo-php-rewrite/file/66effb7b56a0/eclass/eblits.eclass
[2]
http://github.com/GiDiS/gentoo-php-rewrite/blob/master/eclass/eblits.eclass

[-- Attachment #1.2: eblits.eclass --]
[-- Type: text/plain, Size: 1751 bytes --]

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


# eblit-core
# Usage: <function> [version] [eval]
# Main eblit engine
eblit-core() {
	[[ -z $FILESDIR ]] && FILESDIR="$(dirname $EBUILD)/files"
	local e v func=$1 ver=$2 eval_=$3
	for v in ${ver:+-}${ver} -${PVR} -${PV} "" ; do
		e="${FILESDIR}/eblits/${func}${v}.eblit"
		if [[ -e ${e} ]] ; then
			. "${e}"
			[[ ${eval_} == 1 ]] && eval "${func}() { eblit-run ${func} ${ver} ; }"
			return 0
		fi
	done
	return 1
}

# eblit-include
# Usage: [--skip] <function> [version]
# Includes an "eblit" -- a chunk of common code among ebuilds in a given
# package so that its functions can be sourced and utilized within the
# ebuild.
eblit-include() {
	local skipable=false r=0
	[[ $1 == "--skip" ]] && skipable=true && shift
	[[ $1 == pkg_* ]] && skipable=true

	[[ -z $1 ]] && die "Usage: eblit-include <function> [version]"
	eblit-core $1 $2
	r="$?"
	${skipable} && return 0
	[[ "$r" -gt "0" ]] && die "Could not locate requested eblit '$1' in ${FILESDIR}/eblits/"
}

# eblit-run-maybe
# Usage: <function>
# Runs a function if it is defined in an eblit
eblit-run-maybe() {
	[[ $(type -t "$@") == "function" ]] && "$@"
}

# eblit-run
# Usage: <function> [version]
# Runs a function defined in an eblit
eblit-run() {
	eblit-include --skip common "${*:2}"
	eblit-include "$@"
	eblit-run-maybe eblit-$1-pre
	eblit-${PN}-$1
	eblit-run-maybe eblit-$1-post
}

# eblit-pkg
# Usage: <phase> [version]
# Includes the given functions AND evals them so they're included in the binpkgs
eblit-pkg() {
	[[ -z $1 ]] && die "Usage: eblit-pkg <phase> [version]"
	eblit-core $1 $2 1
}


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

Re: [gentoo-dev] RFC: eblits.eclass

[Brian Harring]

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

On Sun, Apr 11, 2010 at 12:06:17AM +0200, Matti Bickel wrote:
> I propose to add eblits.eclass[2] (attached to this message) with the
> purpose and author comments from [1].

Counter proposal; finish off the remaining steps of elib related steps 
from glep33 and integrate it into an EAPI.


> So please enlighten me of any problems you can think of that adding
> eblits.eclass as proposed above would cause. I'd be more than happy if
> we can get an update on elibs progress, too.

Please note that FILESDIR access isn't guranteed during metadata 
sourcing- pkgcore specifically does _not_ set that var to catch ebuild 
screwups.  This is why mips-sources has their eblits loadup w/in 
pkg_setup.

Honestly I'm not much for turning down this particularly pkgcore 
protection since it's caught some screwy access in the past.  The 
problem here is your eblit-php-metadata function- the function is 
executed in the global scope which means it will be validly blocked 
under pkgcore.

Please flip through glep33- the usage of eblits doesn't match their 
original intention there, the intention was to move non metadata 
functionality into libraries to be loaded up after sourcing.  
Basically a compliment to eclasses.  However you're using eblits for 
metadata purposes which is contrary to that intention.

> As the need for such an eclass is very real (we really, really want
> php-5.3 in the tree!), I want to limit discussion to one week, ending
> April 18th. If there are no objections, I'll add the eclass after that date.

In looking through your usage of eblits, I'm not actually seeing any 
reason this technique *must* be used.  Could you please clarify if 
there is some edge case I'm missing requiring eblits?

The reason I ask is that I'd rather see elibs resurrected/finished 
(I'll do the work if no one else will) than have the eblits hackery 
used.

~harring

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