It's based on the PYTHON_SINGLE_TARGET variable concept. For that
reason, I used '-single' in the name. If someone could come up with
a better name, I'd be happy to use it.
It's used on top of python-r1. Similarly, you use ${PYTHON_DEPS} in your
RDEP/DEP; [${PYTHON_USEDEP}] can be used to depend on single- and multi-
implementation packages.
pkg_setup() is exported. It finds the enabled implementation, and
exports EPYTHON and PYTHON.
You aren't allowed to:
1) depend on python-single-r1 packages from python-r1 packages (why
would you?),
2) use python_foreach_impl() -- it will iterate over all implementations
in PYTHON_TARGETS, ignoring PYTHON_SINGLE_TARGET.
---
gx86/eclass/python-single-r1.eclass | 93 +++++++++++++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
create mode 100644 gx86/eclass/python-single-r1.eclass
diff --git a/gx86/eclass/python-single-r1.eclass
b/gx86/eclass/python-single-r1.eclass
new file mode 100644
index 0000000..3d21ea8
--- /dev/null
+++ b/gx86/eclass/python-single-r1.eclass
@@ -0,0 +1,93 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/eclass/python-r1.eclass,v 1.20 2012/11/21
09:04:14 mgorny Exp $
+
+# @ECLASS: python-single-r1
+# @MAINTAINER:
+# Michał Górny <mgo...@gentoo.org>
+# Python herd <pyt...@gentoo.org>
+# @AUTHOR:
+# Author: Michał Górny <mgo...@gentoo.org>
+# Based on work of: Krzysztof Pawlik <nelch...@gentoo.org>
+# @BLURB: An eclass for Python packages not installed for multiple
implementations.
+# @DESCRIPTION:
+# An extension of the python-r1 eclass suite for packages which
+# don't support being installed for multiple Python implementations.
+# This mostly includes tools embedding Python.
+#
+# This eclass extends the IUSE and REQUIRED_USE set by python-r1
+# to request correct PYTHON_SINGLE_TARGET. It also replaces
+# PYTHON_USEDEP and PYTHON_DEPS with a more suitable form.
+#
+# Please note that packages support multiple Python implementations
+# (using python-r1 eclass) can not depend on packages not supporting
+# them (using this eclass).
+#
+# Also, please note that python-single-r1 will always inherit python-r1
+# as well. Thus, all the variables defined and documented there are
+# relevant to the packages using python-single-r1.
+
+case "${EAPI}" in
+ 0|1|2|3)
+ die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+ ;;
+ 4|5)
+ # EAPI=4 needed by python-r1
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
+esac
+
+inherit python-r1
+
+EXPORT_FUNCTIONS pkg_setup
+
+_python_single_set_globals() {
+ local flags=( "${PYTHON_COMPAT[@]/#/python_single_target_}" )
+ local optflags=${flags[@]/%/(+)?}
+
+ IUSE=${flags[*]}
+ REQUIRED_USE="^^ ( ${flags[*]} )"
+ PYTHON_USEDEP+=,${optflags// /,}
+
+ local usestr
+ [[ ${PYTHON_REQ_USE} ]] && usestr="[${PYTHON_REQ_USE}]"
+
+ # 1) well, python-exec would suffice as an RDEP
+ # but no point in making this overcomplex, BDEP doesn't hurt anyone
+ # 2) python-exec should be built with all targets forced anyway
+ # but if new targets were added, we may need to force a rebuild
+ PYTHON_DEPS="dev-python/python-exec[${PYTHON_USEDEP}]"
+ local i
+ for i in "${PYTHON_COMPAT[@]}"; do
+ local d
+ case ${i} in
+ python*)
+ d='dev-lang/python';;
+ jython*)
+ d='dev-java/jython';;
+ pypy*)
+ d='dev-python/pypy';;
+ *)
+ die "Invalid implementation: ${i}"
+ esac
+
+ local v=${i##*[a-z]}
+ PYTHON_DEPS+=" python_single_target_${i}? (
${d}:${v/_/.}${usestr} )"
+ done
+}
+_python_single_set_globals
+
+python-single-r1_pkg_setup() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ for impl in "${_PYTHON_ALL_IMPLS[@]}"; do
+ if has "${impl}" "${PYTHON_COMPAT[@]}" \
+ && use "python_single_target_${impl}"
+ then
+ python_export "${impl}" EPYTHON PYTHON
+ break
+ fi
+ done
+}
--
1.8.0
