On 05/26/2016 18:28, rindeal wrote:
> I've noticed that ebuilds for at least dev-lang/perl and
> sys-libs/glibc are using some concept of "eblits", which seems like
> parts of ebuilds scattered across $FILESDIR with ebuilds containing
> some logic (involving eval) which includes and runs them.
>
> I haven't found any documentation related to them so I'm asking here:
>
> 1) what are they?
> 2) why are they used?
I'm the other user of eblits in sys-kernel/mips-sources. There's a lot of
common code in that package that doesn't need to be duplicated between multiple
ebuilds, so years ago, I converted to using versioned eblits. It's a touch
manual, in that I have to manually check that all consumers of a specific eblit
version are removed from the tree before I remove the deprecated version, but
it avoids the nasty problem of changing an eblit for a newer ebuild that breaks
an older ebuild.
I started on an "eblits.eclass" a few months ago, but sidetracked and didn't
get back to it. Attached, if anyone wants to play with it. It includes the
core eblit loading functions used in mips-sources, which might be more
updated/robust than the ones in glibc (last I checked the logic, but vapier can
clarify if true or not). The last comment block is incomplete. I sidetracked
in finishing item #2 when pondering how to define a global "check" variable in
the eclass itself to control when the eblit core functions were loaded and all
eblits parsed (see latest mips-sources ebuild, $MIPS_SOURCES_EBLITS_LOADED).
Also handles the case of when installing from binary packages and $FILESDIR
isn't available. The eblit source for the pkg_* phases are packed onto the end
of the bzip2 tarball so they're available to Portage & friends.
The core eblit loading functions are the only duplicated code in the
mips-sources ebuilds, as well as glibc and other eblit users (perl?). I don't
remember what the argument for or against eblits might have been back in the
day, but for ebuilds whose only real changes are datestamps and/or version
numbers, eblits are a nice way to encapsulate and share common code that is too
specific for a global eclass. Centralizing the eblit code will allow
mips-sources and glibc ebuilds to shrink their overall filesize a little-bit
more (~1.5KB per mips-sources ebuild, so 3.4KB per ebuild instead of the
current 4.9KB).
And yes, for anyone wondering, I have new mips-sources ebuilds. Just took a
month to partially rewrite the SGI Origin/IP27 kernel code and then hunt down a
hardware bug on my SGI Octane, so, been distracted...
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
# Description: eblit.eclass contains the core functions for creating "eblits".
# eblits are a place to store common code shared among multiple
# ebuilds for a specific package.
#
# Original Eblit Author: Mike Frysinger <vap...@gentoo.org>
# Original Eclass Author: Joshua Kinard <ku...@gentoo.org>
# Maintainer: base-sys...@gentoo.org
# Implementation Note: Since code in an eblit is used by multiple ebuilds,
# PLEASE revbump the eblit files when changes are made. Then update each
# ebuild to use the new eblit version. Remove old eblit versions when there
# are no more consumers. This makes it a lot easier to debug problems with
# the shared code within an eblit, as well as the affected ebuilds.
# To create an eblit:
# 1. Create an "eblits" subdirectory under ${FILESDIR}, if one does not
# already exist.
# 2. Create a new file name using the following formula:
# [a-z0-9_]-v[0-9]+.eblit
# 3. Add the shared code, save, and close the file.
#
# Try to keep eblits specific to the functions they implement. E.g., if a
# number of ebuilds have a large, but common src_unpack() function, and it
# is not already provided by an eclass, then add that code to an eblit named
# "src_unpack-vX.eblit".
# To load and use eblits:
# 1. Inherit the "eblit" eclass (this class).
# 2. Define a new function called "load_eblit_funcs" in the ebuild immediately
# after the global ebuild variables
# eblit-core
# Usage: <function> [version]
# Main eblit engine
eblit-core() {
local e v func=$1 ver=$2
for v in ${ver:+-}${ver} -${PVR} -${PV} "" ; do
e="${FILESDIR}/eblits/${func}${v}.eblit"
if [[ -e ${e} ]] ; then
. "${e}"
[[ ${func} == pkg_* ]] && 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]
# Runs the pkg_* functions AND evals them so they're included in the binpkgs
eblit-pkg() {
[[ -z $1 ]] && die "Usage: eblit-pkg <phase> [version]"
eblit-core pkg_$1 $2
}
