Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
2011/12/29 Brian Harring ferri...@gmail.com: On Thu, Dec 29, 2011 at 02:37:07AM +, Francesco Riosa wrote: 2011/12/28 Zac Medico zmed...@gentoo.org: On 12/28/2011 05:12 AM, Francesco Riosa wrote: Seem to me that append a time slice to the function, in the name or as a parent function that call the underling function can solve most of the versioning/deprecation problems I've overheard Arfrever discussing a similar approach in funtoo's irc channel, where the ebuild would set a variable prior to inherit if it wants to use a specific eclass API. For the python eclass, he's planning to have ebuilds set the PYTHON_ECLASS_API variable to use the new API. When the variable is unset, the eclass will default to the older API. There is a fundamental difference, with timeslices it's not the ebuild that select the implementation but the point in time it's used, or the user forcing a fake time. From what I've read Artfever approach require changes in every ebuild and keeping old functions forever. On the other hand it may be risky to change the preferred interface from the eclass and not the ebuild. Respectfully, the proposals thus far (including python eclass bit) are going in the opposite direction of maintainability, simplicity, robustness. People have problems as is dealing w/ eclasses changing and their dependencies in external repositories not being updated; this complicates that issue and introduces the same potential into gentoo-x86 itself. That's not beneficial. Thing to keep in mind beyond the potential for confusion the proposals entail were they implemented, is the implementation itself. Timeslices? python eclass api versions (when people have problems figuring out the existing, *singular* version)? These things aren't going to be simple which means more than likely, they're going to break, and more than likely it's going to be a PITA to maintain it. Per the norm, I could be wrong, but reading these proposals, they really feel like they need to revisit the notion of maintainability/robustness as an actual full fledged implementation, beyond the (admittedly semi nifty) notion of versioned apis. My 2 cents, hopefully not at my usual offensive level- ~harring yeah, after a good sleep the problems of this approach are more clear, it's a pity, it seemed really bright while eating my spaghetti.
Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
On Wed, 28 Dec 2011 19:36:01 -0800
Brian Harring ferri...@gmail.com wrote:
People have problems as is dealing w/ eclasses changing and their
dependencies in external repositories not being updated; this
complicates that issue and introduces the same potential into
gentoo-x86 itself. That's not beneficial.
I agree with nearly all of that: introducing changes to an eclass
usually means going through the whole tree and fixing what breaks.
That's a lot more easy to fix than adding more layers of indirection
based on a variable's value and adjusting the value according to the
time the ebuild was written versus when the eclass was changed.
Thing to keep in mind beyond the potential for confusion the
proposals entail were they implemented, is the implementation
itself. Timeslices? python eclass api versions (when people have
problems figuring out the existing, *singular* version)? These
things aren't going to be simple which means more than likely,
they're going to break, and more than likely it's going to be a PITA
to maintain it.
Last time I took tranquilisers and set myself up to read python.eclass,
I found that it still doesn't break at 80 characters. Apparently even
that can't be fixed in a timely fashion.
Assing even more layers of mystification like:
if [[ PYTHON_ECLASS_API = 2 ]]; then
python_pkg_setup() {
or even:
python_pkg_setup() {
if [[ PYTHON_ECLASS_API = 2 ]]; then
would be insane, in my opinion.
Also, from the perspective of an ebuild writer, setting
PYTHON_ECLASS_API=2
inherit python
would be meaningless lacking a very clear description of what the
number 2 means.
jer
[gentoo-dev] [PATCH autotools-utils] Support autoreconfiguring packages.
Please note that this is an early sketch. It surely can be improved,
especially with some help on autotools.eclass side which is currently
really hard to co-operate with.
It works very similarly to gnome-autogen.sh. This means that it
automatically determines all the tools needed to run, including gettext,
gtk-doc etc.
---
eclass/autotools-utils.eclass | 102 +++--
1 files changed, 98 insertions(+), 4 deletions(-)
diff --git a/eclass/autotools-utils.eclass b/eclass/autotools-utils.eclass
index 354fdad..54b7d6e 100644
--- a/eclass/autotools-utils.eclass
+++ b/eclass/autotools-utils.eclass
@@ -1,6 +1,6 @@
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/autotools-utils.eclass,v 1.31
2011/12/22 18:01:12 mgorny Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/autotools-utils.eclass,v 1.29
2011/11/27 09:57:20 mgorny Exp $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
@@ -93,10 +93,28 @@ case ${EAPI:-0} in
*) die EAPI=${EAPI} is not supported ;;
esac
+# @ECLASS-VARIABLE: AUTOTOOLS_AUTORECONF
+# @DEFAULT-UNSET
+# @DESCRIPTION:
+# Set to enable running autoreconf in src_prepare() and adding autotools
+# dependencies.
+#
+# The eclass will try to determine the correct autotools to run including a few
+# external tools: gettext, glib-gettext, intltool, gtk-doc, gnome-doc-prepare.
+# If your tool is not supported, please open a bug and we'll add support for
it.
+#
+# Note that dependencies are added for autoconf, automake and libtool only.
+# If your package needs one of the external tools listed above, you need to add
+# appropriate packages to DEPEND yourself.
+[[ ${AUTOTOOLS_AUTORECONF} ]] || _autotools_auto_dep=no
+
+AUTOTOOLS_AUTO_DEPEND=${_autotools_auto_dep} \
inherit autotools eutils libtool
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
+unset _autotools_auto_dep
+
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -250,20 +268,96 @@ remove_libtool_files() {
fi
}
+# @FUNCTION: autotools-utils_autoreconf
+# @DESCRIPTION:
+# Reconfigure the sources (like gnome-doc-autogen.sh or eautoreconf).
+autotools-utils_autoreconf() {
+ debug-print-function ${FUNCNAME} $@
+
+ # Override this func to not require unnecessary eaclocal calls.
+ autotools_check_macro() {
+ local x
+
+ # Add a few additional variants as we don't get expansions.
+ [[ ${1} = AC_CONFIG_HEADERS ]] set -- ${@} AC_CONFIG_HEADER
+
+ for x; do
+ grep -h ^${x} configure.{ac,in} 2/dev/null
+ done
+ }
+
+ einfo Autoreconfiguring '${PWD}' ...
+
+ local auxdir=$(sed -n -e 's/^AC_CONFIG_AUX_DIR(\(.*\))$/\1/p' \
+ configure.{ac,in} 2/dev/null)
+ if [[ ${auxdir} ]]; then
+ auxdir=${auxdir%%]}
+ mkdir -p ${auxdir##[}
+ fi
+
+ # Support running additional tools like gnome-autogen.sh.
+ # Note: you need to add additional depends to the ebuild.
+
+ # gettext
+ if [[ $(autotools_check_macro AM_GLIB_GNU_GETTEXT) ]]; then
+ echo 'no' | autotools_run_tool glib-gettextize --copy
+ elif [[ $(autotools_check_macro AM_GNU_GETTEXT) ]]; then
+ eautopoint
+ fi
+
+ # intltool
+ if [[ $(autotools_check_macro AC_PROG_INTLTOOL IT_PROG_INTLTOOL) ]]
+ then
+ autotools_run_tool intltoolize --copy --automake
+ fi
+
+ # gtk-doc
+ if [[ $(autotools_check_macro GTK_DOC_CHECK) ]]; then
+ autotools_run_tool gtkdocize --copy
+ fi
+
+ # gnome-doc
+ if [[ $(autotools_check_macro GNOME_DOC_INIT) ]]; then
+ autotools_run_tool gnome-doc-prepare --copy
+ fi
+
+ # We need to perform the check twice to know whether to run eaclocal.
+ # (_elibtoolize does that itself)
+ if [[ $(autotools_check_macro AC_PROG_LIBTOOL AM_PROG_LIBTOOL LT_INIT)
]]
+ then
+ _elibtoolize --copy --force --install
+ else
+ eaclocal
+ fi
+
+ eautoconf
+ eautoheader
+ eautomake
+
+ local x
+ for x in $(autotools_get_subdirs); do
+ if [[ -d ${x} ]] ; then
+ pushd ${x} /dev/null
+ autotools-utils_eautoreconf
+ popd /dev/null
+ fi
+ done
+}
+
# @FUNCTION: autotools-utils_src_prepare
# @DESCRIPTION:
# The src_prepare function.
#
# Supporting PATCHES array and user patches. See base.eclass(5) for reference.
-#
-# This function calls elibtoolize implicitly. If you need to call eautoreconf
-# afterwards, please use AT_NOELIBTOOLIZE=yes to avoid it being called twice.
autotools-utils_src_prepare() {
debug-print-function ${FUNCNAME} $@
+
