FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-10-2010, 10:06 PM
Matti Bickel
 
Default RFC: eblits.eclass

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
# 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
}
 
Old 04-11-2010, 04:30 AM
Brian Harring
 
Default RFC: eblits.eclass

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
 

Thread Tools




All times are GMT. The time now is 02:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org