[gentoo-dev] New eclass: autotools-utils.eclass

[gentoo-dev] New eclass: autotools-utils.eclass

[Maciej Mrozowski]

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

After gathering some feedback, after addressing reported issues, now I feel 
it's ready for public consumption. especially when static-libs is being used 
more and more often. It's purpose is to become standard eclass for autotools 
build systems.

Brief description:
autotools-utils.eclass is autotools.eclass (so libtool.eclass) and base.eclass 
(so eutils.eclass) wrapper providing all inherited features (it is guaranteed, 
no need to additionally inherit any of those) along with econf arguments as 
Bash array, out of source build with overridable build dir location, static 
archives handling, libtool files removal, enable/disable debug handling. It's 
modelled after cmake-utils and resembles it in many aspects for consistency.

Notable features:
- eautoreconf, eautomake, elibtoolize, eaclocal functions (from autotools)
- PATCHES and user patches support (from base)
- DOCS and HTML_DOCS arrays support (from base)
- myeconfargs - econf arguments as Bash array (usage like mycmakeargs in 
cmake-utils, if used, needs to be defined just before autotools-
utils_src_configure call)
- out of source build (enabled by default) with overridable build dir location
- static archives handling (static-libs in IUSE)
- automatic removal of unnecessary static archives (usually for plugins, 
determined by presence of shouldnotlink=yes libtool property)
- libtool files removal (static-libs in IUSE, determined by absence of 
shouldnotlink=yes libtool property)
- enable/disable-debug handing (debug in IUSE)
- remove_libtool_files function to help override libtool removal behaviour 
(you shouldn't need it, any usage or this function with parameter 'none' will 
be reported and punished :p)

Restrictions:
- only >= EAPI-2 supported (this is intentional as src_prepare phase is 
provided, EAPI-0,1 would mean providing src_unpack as well, which is 
unacceptable for build system eclasses)

Attached two example ebuilds.
Refer to eclass manual page for details or more extensive example usage.

-- 
regards
MM

[-- Attachment #1.2: autotools-utils.eclass --]
[-- Type: text/plain, Size: 7177 bytes --]

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

# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# Maciej Mrozowski <reavertm@gentoo.org>
# @BLURB: common ebuild functions for autotools-based packages
# @DESCRIPTION:
# autotools-utils.eclass is autotools.eclass(5) and base.eclass(5) wrapper
# providing all inherited features along with econf arguments as Bash array,
# out of source build with overridable build dir location, static archives
# handling, libtool files removal, enable/disable debug handling.
#
# @EXAMPLE:
# Typical ebuild using autotools-utils.eclass:
#
# @CODE
# EAPI="2"
#
# inherit autotools-utils
#
# DESCRIPTION="Foo bar application"
# HOMEPAGE="http://example.org/foo/"
# SRC_URI="mirror://sourceforge/foo/${P}.tar.bz2"
#
# LICENSE="LGPL-2.1"
# KEYWORDS=""
# SLOT="0"
# IUSE="debug doc examples qt4 static-libs tiff"
#
# CDEPEND="
# 	media-libs/libpng:0
# 	qt4? (
# 		x11-libs/qt-core:4
# 		x11-libs/qt-gui:4
# 	)
# 	tiff? ( media-libs/tiff:0 )
# "
# RDEPEND="${CDEPEND}
# 	!media-gfx/bar
# "
# DEPEND="${CDEPEND}
# 	doc? ( app-doc/doxygen )
# "
#
# # bug 123456
# AUTOTOOLS_IN_SOURCE_BUILD=1
#
# DOCS=(AUTHORS ChangeLog README "Read me.txt" TODO)
#
# PATCHES=(
# 	"${FILESDIR}/${P}-gcc44.patch" # bug 123458
# 	"${FILESDIR}/${P}-as-needed.patch"
# 	"${FILESDIR}/${P}-unbundle_libpng.patch"
# )
#
# src_configure() {
# 	myeconfargs=(
# 		$(use_with qt4)
# 		$(use_enable threads multithreading)
# 		$(use_with tiff)
# 	)
# 	autotools-utils_src_configure
# }
#
# src_compile() {
# 	autotools-utils_src_compile
# 	use doc && autotools-utils_src_compile docs
# }
#
# src_install() {
# 	use doc && HTML_DOCS=("${AUTOTOOLS_BUILD_DIR}/apidocs/html/")
# 	autotools-utils_src_install
# 	if use examples; then
# 		dobin "${AUTOTOOLS_BUILD_DIR}"/foo_example{1,2,3} \\
# 			|| die 'dobin examples failed'
# 	fi
# }
#
# @CODE

# Keep variable names synced with cmake-utils and the other way around!

case ${EAPI:-0} in
	2|3|4) ;;
	*) DEPEND="EAPI-TOO-OLD" ;;
esac

inherit autotools base

EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test

# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Build directory, location where all autotools generated files should be
# placed. For out of source builds it defaults to ${WORKDIR}/${P}_build.

# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.

# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Specify location of autotools' configure script. By default it uses ${S}.

# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# Optional econf arguments as Bash array. Should be defined before calling src_configure.
# @CODE
# src_configure() {
# 	myeconfargs=(
# 		--disable-readline
# 		--with-confdir="/etc/nasty foo confdir/"
# 		$(use_enable debug cnddebug)
# 		$(use_enable threads multithreading)
# 	)
# 	autotools-utils_src_configure
# }
# @CODE

# Determine using IN or OUT source build
_check_build_dir() {
	: ${ECONF_SOURCE:=${S}}
	if [[ -n ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
		AUTOTOOLS_BUILD_DIR="${ECONF_SOURCE}"
	else
		: ${AUTOTOOLS_BUILD_DIR:=${WORKDIR}/${P}_build}
	fi
	echo ">>> Working in BUILD_DIR: \"$AUTOTOOLS_BUILD_DIR\""
}

# @FUNCTION: remove_libtool_files
# @USAGE: [all|none]
# @DESCRIPTION:
# Determines unnecessary libtool files (.la) and libtool static archives (.a)
# and removes them from installation image.
# To unconditionally remove all libtool files, pass 'all' as argument.
# To leave all libtool files alone, pass 'none' as argument.
# Unnecessary static archives are removed in any case.
#
# In most cases it's not necessary to manually invoke this function.
# See autotools-utils_src_install for reference.
remove_libtool_files() {
	debug-print-function ${FUNCNAME} "$@"

	local f
	for f in $(find "${D}" -type f -name '*.la'); do
		# Keep only .la files with shouldnotlink=yes - likely plugins
		local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' "${f}")
		if [[  "$1" == 'all' || -z ${shouldnotlink} ]]; then
			if [[ "$1" != 'none' ]]; then
				echo "Removing unnecessary ${f}"
				rm -f "${f}"
			fi
		fi
		# Remove static libs we're not supposed to link against
		if [[ -n ${shouldnotlink} ]]; then
			local remove=${f/%.la/.a}
			[[ "${f}" != "${remove}" ]] || die 'regex sanity check failed'
			echo "Removing unnecessary ${remove}"
			rm -f "${remove}"
		fi
	done
}

# @FUNCTION: autotools-utils_src_prepare
# @DESCRIPTION:
# The src_prepare function.
#
# Supporting PATCHES array and user patches. See base.eclass(5) for reference.
autotools-utils_src_prepare() {
	debug-print-function ${FUNCNAME} "$@"

	base_src_prepare
}

# @FUNCTION: autotools-utils_src_configure
# @DESCRIPTION:
# The src_configure function. For out of source build it creates build
# directory and runs econf there. Configuration parameters defined
# in myeconfargs are passed here to econf. Additionally following USE
# flags are known:
#
# IUSE="debug" passes --disable-debug/--enable-debug to econf respectively.
#
# IUSE="static-libs" passes --enable-shared and either --disable-static/--enable-static
# to econf respectively.
autotools-utils_src_configure() {
	debug-print-function ${FUNCNAME} "$@"

	# Common args
	local econfargs=()

	# Handle debug found in IUSE
	if has debug ${IUSE//+}; then
		econfargs+=($(use_enable debug))
	fi

	# Handle static-libs found in IUSE, disable them by default
	if has static-libs ${IUSE//+}; then
		econfargs+=(
			--enable-shared
			$(use_enable static-libs static)
		)
	fi

	# Append user args
	econfargs+=(${myeconfargs[@]})

	_check_build_dir
	mkdir -p "${AUTOTOOLS_BUILD_DIR}" || die "mkdir '${AUTOTOOLS_BUILD_DIR}' failed"
	pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null
	base_src_configure "${econfargs[@]}"
	popd > /dev/null
}

# @FUNCTION: autotools-utils_src_compile
# @DESCRIPTION:
# The autotools src_compile function, invokes emake in specified AUTOTOOLS_BUILD_DIR.
autotools-utils_src_compile() {
	debug-print-function ${FUNCNAME} "$@"

	_check_build_dir
	pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null
	base_src_compile "$@"
	popd > /dev/null
}

# @FUNCTION: autotools-utils_src_install
# @DESCRIPTION:
# The autotools src_install function. Runs emake install, unconditionally
# removes unnecessary static libs (based on shouldnotlink libtool property)
# and removes unnecessary libtool files when static-libs USE flag is defined
# and unset.
#
# DOCS and HTML_DOCS arrays are supported. See base.eclass(5) for reference.
autotools-utils_src_install() {
	debug-print-function ${FUNCNAME} "$@"

	_check_build_dir
	pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null
	base_src_install
	popd > /dev/null

	# Remove libtool files and unnecessary static libs
	local args
	has static-libs ${IUSE//+} && ! use static-libs || args='none'
	remove_libtool_files ${args}
}

# @FUNCTION: autotools-utils_src_test
# @DESCRIPTION:
# The autotools src_test function. Runs emake check in build directory.
autotools-utils_src_test() {
	debug-print-function ${FUNCNAME} "$@"

	_check_build_dir
	pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null
	# Run default src_test as defined in ebuild.sh
	default_src_test
	popd > /dev/null
}

[-- Attachment #1.3: example --]
[-- Type: text/plain, Size: 804 bytes --]

# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/media-libs/plib/plib-1.8.5.ebuild,v 1.6 2009/12/26 16:59:50 armin76 Exp $

EAPI=2

WANT_AUTOCONF=2.5
WANT_AUTOMAKE=1.9
inherit autotools-utils

DESCRIPTION="multimedia library used by many games"
HOMEPAGE="http://plib.sourceforge.net/"
SRC_URI="http://plib.sourceforge.net/dist/${P}.tar.gz"

LICENSE="LGPL-2"
SLOT="0"
KEYWORDS="~alpha ~amd64 ~hppa ~ppc ~sparc ~x86"
IUSE="static-libs"

RDEPEND="
	media-libs/libsdl
	virtual/glut
	virtual/opengl
"
DEPEND="${RDEPEND}"

PATCHES=(
	"${FILESDIR}/${P}-shared-libs.patch"
)

DOCS=(AUTHORS ChangeLog KNOWN_BUGS NOTICE README TODO-1.6 TODO-2.0 TODO_AFTER135)

src_prepare() {
	autotools-utils_src_prepare
	eautoreconf
}

[-- Attachment #1.4: example --]
[-- Type: text/plain, Size: 1163 bytes --]

# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-libs/libgadu/libgadu-1.9.0-r1.ebuild,v 1.6 2010/07/08 17:41:24 ranger Exp $

EAPI="2"

MY_P="${P/_/-}"

inherit autotools-utils

DESCRIPTION="This library implements the client side of the Gadu-Gadu protocol"
HOMEPAGE="http://toxygen.net/libgadu/"
SRC_URI="http://toxygen.net/libgadu/files/${MY_P}.tar.gz"

LICENSE="LGPL-2.1"
KEYWORDS="alpha amd64 hppa ia64 ~mips ~ppc ppc64 sparc x86 ~x86-fbsd ~x86-freebsd ~amd64-linux ~x86-linux ~ppc-macos"
SLOT="0"
IUSE="doc ssl static-libs threads"

COMMON_DEPEND="
	ssl? ( >=dev-libs/openssl-0.9.6m )
"
DEPEND="${COMMON_DEPEND}
	doc? ( app-doc/doxygen )
"
RDEPEND="${COMMON_DEPEND}
	!=net-im/kadu-0.6.0.2
	!=net-im/kadu-0.6.0.1
"

S="${WORKDIR}/${MY_P}"

PATCHES=(
	"${FILESDIR}/${P}-memleak.patch"
)

AUTOTOOLS_IN_SOURCE_BUILD=1

DOCS=(AUTHORS ChangeLog NEWS README)

src_configure() {
	myeconfargs=(
		$(use_with ssl openssl)
		$(use_with threads pthread)
	)
	autotools-utils_src_configure
}

src_install() {
	use doc && HTML_DOCS=(docs/html/)
	autotools-utils_src_install
}

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

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Petteri Räty]

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

On 07/17/2010 01:53 PM, Maciej Mrozowski wrote:
> After gathering some feedback, after addressing reported issues, now I feel 
> it's ready for public consumption. especially when static-libs is being used 
> more and more often. It's purpose is to become standard eclass for autotools 
> build systems.
> 
> Brief description:
> autotools-utils.eclass is autotools.eclass (so libtool.eclass) and base.eclass 
> (so eutils.eclass) wrapper providing all inherited features (it is guaranteed, 
> no need to additionally inherit any of those) along with econf arguments as 
> Bash array, out of source build with overridable build dir location, static 
> archives handling, libtool files removal, enable/disable debug handling. It's 
> modelled after cmake-utils and resembles it in many aspects for consistency.
> 

Maybe choose some other name. For me -utils in an eclass name means a
set of helper functions. I would name it so the name reflects that it's
meant to be used as the main build system provider.

Regards,
Petteri


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

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Maciej Mrozowski]

On Saturday 17 of July 2010 13:03:33 Petteri Räty wrote:
> On 07/17/2010 01:53 PM, Maciej Mrozowski wrote:
> > After gathering some feedback, after addressing reported issues, now I
> > feel it's ready for public consumption. especially when static-libs is
> > being used more and more often. It's purpose is to become standard
> > eclass for autotools build systems.
> > 
> > Brief description:
> > autotools-utils.eclass is autotools.eclass (so libtool.eclass) and
> > base.eclass (so eutils.eclass) wrapper providing all inherited features
> > (it is guaranteed, no need to additionally inherit any of those) along
> > with econf arguments as Bash array, out of source build with overridable
> > build dir location, static archives handling, libtool files removal,
> > enable/disable debug handling. It's modelled after cmake-utils and
> > resembles it in many aspects for consistency.
> 
> Maybe choose some other name. For me -utils in an eclass name means a
> set of helper functions. I would name it so the name reflects that it's
> meant to be used as the main build system provider.

It's for consistency with existing cmake-utils.eclass, which is main cmake 
buildsystem provider (no idea why it wasn't called just 'cmake' by initial 
commiters). Unfortunately autotools name is already taken and extending 
autotools so much (adding new defined phases) is not possible (nor is 
renaming) as far as I understand.

-- 
regards
MM

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Alexis Ballier]

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

case ${EAPI:-0} in
	2|3|4) ;;
	*) DEPEND="EAPI-TOO-OLD" ;;
esac

why not:

case ${EAPI:-0} in
	0|1) DEPEND="EAPI-TOO-OLD" ;;
esac

?

Alexis.

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

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Brian Harring]

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

On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote:
> case ${EAPI:-0} in
> 	2|3|4) ;;
> 	*) DEPEND="EAPI-TOO-OLD" ;;
> esac
> 
> why not:
> 
> case ${EAPI:-0} in
> 	0|1) DEPEND="EAPI-TOO-OLD" ;;
> esac

Do not go adding invalid DEPEND like that.  Make the eclass die 
instead.

Seriously, and this is a general rant based on several years of 
people adding stupid shit without considering the fallout:

Whatever great new little trick you can think of for stuff like 
this... it's wrong.  Use the mechanisms that exist.  If policy 
forbids it, fix the policy, don't come up w/ "clever" hacks around 
it.  Fix the core issue instead.

Wouldn't surprise me if portage would accept this and run with it, 
blowing up at emerge time instead.  Pkgcore and paludis however will 
give you the finger *very* quickly since that's not a valid atom.  
Don't piss on our parties w/ 'clever' tricks, do the right thing and 
use a die.

People will move their ass a helluva lot quicker when their ebuild 
breaks than when bones has to go yelling both at the eclass author, 
and the devs in question about missing deps.

Do not add this to the tree.
~harring

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

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18-07-2010 00:58, Brian Harring wrote:
> On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote:
>> case ${EAPI:-0} in
>> 	2|3|4) ;;
>> 	*) DEPEND="EAPI-TOO-OLD" ;;
>> esac
>>
>> why not:
>>
>> case ${EAPI:-0} in
>> 	0|1) DEPEND="EAPI-TOO-OLD" ;;
>> esac

Alexis,

the problem with your alternative is that it's "too clever" and won't
die/kill/stop the processing of the eclass for newer EAPIs that at any
point in time no one can be sure will be compatible with the current
eclass design.
That's why it has been agreed that eclasses should specifically list all
supported EAPI versions and die/kill/stop on all other EAPI versions.

> Do not go adding invalid DEPEND like that.  Make the eclass die 
> instead.

Brian,

this is being used in the tree already.
IIRC, since the introduction of EAPI-2 in the tree, there were a few
solutions present to the dev ml and the one agreed by people was the
abuse of depend to have the PM fail on dependency resolution instead of
calling die on an eclass - which iirc is / was forbidden by PMS.
We can discuss the correctness of this use, but please take into account
it's already being used so until we have such a discussion we can't
"forbid" its use.

grep EAPI-TOO-OLD $(portageq portdir)/eclass/*
/home/gentoo-cvs/gentoo-x86/eclass/kde4-functions.eclass:       *)
DEPEND="EAPI-TOO-OLD" ;;
/home/gentoo-cvs/gentoo-x86/eclass/poppler.eclass:has 2 ${EAPI} ||
DEPEND="EAPI-TOO-OLD"
/home/gentoo-cvs/gentoo-x86/eclass/virtuoso.eclass:     *)
DEPEND='EAPI-TOO-OLD' ;;

> Seriously, and this is a general rant based on several years of 
> people adding stupid shit without considering the fallout:
> 
> Whatever great new little trick you can think of for stuff like 
> this... it's wrong.  Use the mechanisms that exist.  If policy 
> forbids it, fix the policy, don't come up w/ "clever" hacks around 
> it.  Fix the core issue instead.
> 
> Wouldn't surprise me if portage would accept this and run with it, 
> blowing up at emerge time instead.  Pkgcore and paludis however will 
> give you the finger *very* quickly since that's not a valid atom.  
> Don't piss on our parties w/ 'clever' tricks, do the right thing and 
> use a die.
> 
> People will move their ass a helluva lot quicker when their ebuild 
> breaks than when bones has to go yelling both at the eclass author, 
> and the devs in question about missing deps.
> 
> Do not add this to the tree.

See above that this is already in the tree and has been for a few months
(years?)

> ~harring

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMQl7jAAoJEC8ZTXQF1qEPQuIQANWeUwpZFNfsY6wkDWCOI+xR
p4sYPRiHStY4nCJ6IZ/DGvBNnrvo+KDn3P5vT9uHT4x50cE5bYeyz4l+DCjXYtCp
ey7rGL3P7l9vNtf6Vg7+8imaGbgGnr2mZQ8Pmn1ZWXaYW8i2e5yyTeUpvqH3TH2v
ASKYIg5VlS3MeiP2unOQfuLXqRDcyXxMPnG6xj3pl2PpGMT3X+rAAkLDqGKRcZJj
7uA0oVUdjWM5HTKqZKYRbYpLo5veawVC+FMR4Z4DA6yhgtYsUQ+mTYnfjGgavCah
KU881TUaZQajDSXVK4m1V8q8Zg0ge0vjeXN15CPhPFfnSyCqf6GbkPZE7OjizJdu
vA8uoYjEMNXTAnE+TS1h18I+Cs3rL8CA+sxbHZgING5cfg8DtfRRW02zJzicaLxP
tIlotZpefEKWrTBKPrfGjhk0Te/IjvUAyLfx77Q5qqKxihBxy9T0DSe7TA0Azwkk
B9eW9Cn1UeoHeV1M+/kD4oXna+d66rOHLXP7LerQjm7ZqII5MwGRA7yC7RhGDyvO
oCsOCii9iuBR5n+qc8dvlN9oYyrVuDE22a4LsBGSXIse9Z8C1fBayUwYTkbAJLA0
uKqYvElfvJoH9hjJud01iQtQ7GxTEdlT0HaeV085Tvq6D/eoK1U+tGlTeFZXNkFb
+6R9ncUuA0AeKcfVvJ2P
=8vjx
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Brian Harring]

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

On Sun, Jul 18, 2010 at 01:54:43AM +0000, Jorge Manuel B. S. Vicetto wrote:
> this is being used in the tree already.

Doesn't make it right ;)

> IIRC, since the introduction of EAPI-2 in the tree, there were a few
> solutions present to the dev ml and the one agreed by people was the
> abuse of depend to have the PM fail on dependency resolution instead of
> calling die on an eclass - which iirc is / was forbidden by PMS.

PMS has no such restriction as far as I know (or can grep for).  
Regardless, if PMS *did* forbid die's in eclass global scope... pretty 
much it's there already (including for when EAPI isn't at the correct 
value).

Basically, a die can be dealt with better than broken atom's- 
DEPEND=eapi-too-old definitely conflicts w/ PMS (invalid atom), if die 
does in this case... the lesser of two evils is die.

If PMS doesn't conflict (which I'm pretty sure it doesn't), then that 
leaves die as the proper approach.


> We can discuss the correctness of this use, but please take into account
> it's already being used so until we have such a discussion we can't
> "forbid" its use.

Yes we can.  The fact it slipped in via 3 places that no one noticed 
doesn't mean it's now considerable acceptable.  This is part of what 
triggered my rant- the tree is large and vast, sometimes monsters 
manage to get added and lurk for a while.  That doesn't make them 
defacto standard however.

At the time of it's addition, it was invalid from the parsing 
standpoint- it shouldn't have been added in the first place because of 
that.

As for converting it to die, that can be done _now_ without fallout- 
if anything was triggering that codepath bones should've been 
complaining about it (yet to hear any such complaints).

~harring

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

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Maciej Mrozowski]

On Sunday 18 of July 2010 03:54:43 Jorge Manuel B. S. Vicetto wrote:

> grep EAPI-TOO-OLD $(portageq portdir)/eclass/*
> /home/gentoo-cvs/gentoo-x86/eclass/kde4-functions.eclass:       *)
> DEPEND="EAPI-TOO-OLD" ;;
> /home/gentoo-cvs/gentoo-x86/eclass/poppler.eclass:has 2 ${EAPI} ||
> DEPEND="EAPI-TOO-OLD"
> /home/gentoo-cvs/gentoo-x86/eclass/virtuoso.eclass:     *)
> DEPEND='EAPI-TOO-OLD' ;;

status quo should be challenged occasionally.

Fixed autotools-utils.eclass, kde4-functions.eclass, virtuoso.eclass
 case ${EAPI:-0} in
        2|3|4) ;;
-       *) DEPEND="EAPI-TOO-OLD" ;;                                                                                 
+       *) die "EAPI=${EAPI} is not supported" ;;                                                                   
 esac                                                                                                               

Remaining poppler.eclass is not used anymore and probably subject to remove.

-- 
regards
MM

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Ciaran McCreesh]

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

On Mon, 19 Jul 2010 18:23:36 +0200
Maciej Mrozowski <reavertm@gmail.com> wrote:
> status quo should be challenged occasionally.
> 
> Fixed autotools-utils.eclass, kde4-functions.eclass, virtuoso.eclass
>  case ${EAPI:-0} in
>         2|3|4) ;;
> -       *)
> DEPEND="EAPI-TOO-OLD" ;;                                                                                 
> +       *) die "EAPI=${EAPI} is not
> supported" ;;
> esac                                                                                                               

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-functions.eclass?r1=1.18&r2=1.19&

This was changed for a reason. Did you find out what that reason was
before reverting it?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Francesco R]

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

2010/7/19 Ciaran McCreesh <ciaran.mccreesh@googlemail.com>

> On Mon, 19 Jul 2010 18:23:36 +0200
> Maciej Mrozowski <reavertm@gmail.com> wrote:
> > status quo should be challenged occasionally.
> >
> > Fixed autotools-utils.eclass, kde4-functions.eclass, virtuoso.eclass
> >  case ${EAPI:-0} in
> >         2|3|4) ;;
> > -       *)
> > DEPEND="EAPI-TOO-OLD" ;;
> > +       *) die "EAPI=${EAPI} is not
> > supported" ;;
> > esac
>
>
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-functions.eclass?r1=1.18&r2=1.19&
>
> This was changed for a reason. Did you find out what that reason was
> before reverting it?
>

the comment for that commit is:
"Update kde4 eclasses from kde-testing. Mostly minor sinc. Introduce support
for stable koffice2"
So, since the reason it's not mentioned, the reason is not existent.
</could_not_resist>

>
> --
> Ciaran McCreesh
>

[-- Attachment #2: Type: text/html, Size: 2037 bytes --]

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Alexis Ballier]

On Sunday 18 July 2010 04:54:43 Jorge Manuel B. S. Vicetto wrote:
> On 18-07-2010 00:58, Brian Harring wrote:
> > On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote:
> >> case ${EAPI:-0} in
> >> 
> >> 	2|3|4) ;;
> >> 	*) DEPEND="EAPI-TOO-OLD" ;;
> >> 
> >> esac
> >> 
> >> why not:
> >> 
> >> case ${EAPI:-0} in
> >> 
> >> 	0|1) DEPEND="EAPI-TOO-OLD" ;;
> >> 
> >> esac
> 
> Alexis,
> 
> the problem with your alternative is that it's "too clever" and won't
> die/kill/stop the processing of the eclass for newer EAPIs that at any
> point in time no one can be sure will be compatible with the current
> eclass design.
> That's why it has been agreed that eclasses should specifically list all
> supported EAPI versions and die/kill/stop on all other EAPI versions.

Fair enough. Why is EAPI 4 in that list then ? Has it been approved/finalized 
yet ?

Alexis.

Re: [gentoo-dev] New eclass: autotools-utils.eclass

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20-07-2010 04:55, Alexis Ballier wrote:
> On Sunday 18 July 2010 04:54:43 Jorge Manuel B. S. Vicetto wrote:
>> On 18-07-2010 00:58, Brian Harring wrote:
>>> On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote:
>>>> case ${EAPI:-0} in
>>>>
>>>> 	2|3|4) ;;
>>>> 	*) DEPEND="EAPI-TOO-OLD" ;;
>>>>
>>>> esac
>>>>
>>>> why not:
>>>>
>>>> case ${EAPI:-0} in
>>>>
>>>> 	0|1) DEPEND="EAPI-TOO-OLD" ;;
>>>>
>>>> esac
>>
>> Alexis,
>>
>> the problem with your alternative is that it's "too clever" and won't
>> die/kill/stop the processing of the eclass for newer EAPIs that at any
>> point in time no one can be sure will be compatible with the current
>> eclass design.
>> That's why it has been agreed that eclasses should specifically list all
>> supported EAPI versions and die/kill/stop on all other EAPI versions.
> 
> Fair enough. Why is EAPI 4 in that list then ? Has it been approved/finalized 
> yet ?

You raise an important point that had slipped my reading.
EAPI-4 spec was approved by the council some time ago. Actually it was
EAPI-3, but then there was a decision to get EAPI-3 as EAPI-2 + prefix
support and use the approved spec for EAPI-4.
However, the EAPI-4 spec is still pending Portage implementation and
thus it's my opinion that no eclass in the tree should state
compatibility with it as we don't want eclasses claiming compatibility
with an EAPI that is yet to be implemented.

> Alexis.
> 

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMRW29AAoJEC8ZTXQF1qEPzmgQAJ4X4r7n4PN0egqYAe/1cuJp
LtLQqQnL0CWkZIKp4k3ygGm9GolOJ7glB4FWkak9XcXoioyY6fU5hNY9rDAphjM4
8EcMeF2gTD1obiqPJps+dwU83vRRh9QzyvxXMRaqZc3n2ydvOXpH3G9/uJ3sv7y7
uBY0UnCGPg8IyaciEBuruNHb4uJsbGdORJvqFRgGTWR6FwdXV7tOWpL185mz8qja
akDAA5pjcmmVbJmAANfWOrYzc+05lCKFsNTfoDiZEs7awtDmsoxcS0pKy/XJ7iLl
hc/dVC2DquOpC6qOM8oTulxzGnfCLDlQ+hlIihbFhMjMUyzyLn2APA3GAUQdz76d
dmp8VqLQrXKDVh8GtYZyrkA8yiD18R8GT427v0NdMQpG+5fi2UqHqRBHZCE1Z+Vq
gnPRekTdpPTGJE8CcLgt+LzG8j7lP+omS9hT8TRYOQXvM34XVKOo1h7kw5nXYll1
exqYQmGo9FeT5Fn5eSdgquqJP83WIIf+Fi6hhegYeTPDyYmRnilFCDmw4tt5S5fI
Ta16FwIwmK5G6DHdz/OK+wlcWrMC2iKHcll8oowHfobvPBD5vEyl16ln7WFkgf4q
TabMxk8ImTTQvEQcE829vTExtwqwoJ3JPrFmR5g4EQ7Re9f2ngZ89jz1fTyQYz9R
pLUXQfw8Jg9qc1JypqaU
=hMJr
-----END PGP SIGNATURE-----