[gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Michał Górny]

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

Hi,

I've thought for a bit and got the conclusion that the best solution
for quite an irritating syntax of autotools-multilib is to use
sub-phase functions. To increase consistency between ebuilds, the same
phases can be used in autotools-utils directly.

The idea is that current ebuild looking like:

  src_prepare() {
    sed ...
    autotools-utils_src_prepare
  }

  src_configure() {
    local myeconfargs=(
      --with-foo
      --with-bar
    )
    autotools-utils_src_configure
  }

  src_install() {
    use doc && local HTML_DOCS=...

    autotools-utils_src_install

    doinitd ...
    dobin "${BUILD_DIR}"/something/something
  }

could be written as:

  autotools_configure() {
    local myeconfargs=(
      --with-foo
      --with-bar
    )
    edefault
  }

  autotools_install() {
    edefault
    dobin something/something
  }

  autotools_install_all() {
    use doc && local HTML_DOCS=...

    edefault

    doinitd ...
  }

While this seems rather cosmetic, it becomes incredibly helpful when it
comes to multilib or working inside BUILD_DIR.

The sub-phases without '_all' suffix are run inside BUILD_DIR, and
repeated for each multilib ABI. The sub-phases with '_all' are always
run only once, and inside S.

This provides a meaningful split between the two parts
of autotools-utils_src_install (and default_src_install too), and makes
it possible to hack stuff in multilib without having to rewrite
the 'multilib_foreach_impl' lines all the time.

For example:

  src_configure() {
    my_configure() {
      local myeconfargs=(
        ... # something ABI-conditional here
      )
      autotools-utils_src_configure
    }
    multilib_parallel_foreach_abi my_configure
  }

can be replaced with much simpler:

  autotools_configure() {
    local myeconfargs=(
      ... # something ABI-conditional here
    )
    edefault
  }

What are your thoughts? The patch is sent in reply to this mail.

-- 
Best regards,
Michał Górny

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

[gentoo-dev] [PATCH] Introduce autotools_* sub-phase functions to make overriding easier.

[Michał Górny]

More details in the mail preceding the patch.
---
 gx86/eclass/autotools-multilib.eclass |  47 ++++++++--
 gx86/eclass/autotools-utils.eclass    | 157 +++++++++++++++++++++++++---------
 2 files changed, 158 insertions(+), 46 deletions(-)

diff --git a/gx86/eclass/autotools-multilib.eclass b/gx86/eclass/autotools-multilib.eclass
index 5ca8112..6156610 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -38,27 +38,62 @@ autotools-multilib_src_prepare() {
 }
 
 autotools-multilib_src_configure() {
-	multilib_parallel_foreach_abi autotools-utils_src_configure "${@}"
+	if declare -f autotools_configure >/dev/null; then
+		multilib_parallel_foreach_abi \
+			_autotools-utils_run_phase autotools_configure "${@}"
+	else
+		multilib_parallel_foreach_abi \
+			_autotools-utils_run_phase \
+			autotools-utils_autotools_configure "${@}"
+	fi
 }
 
 autotools-multilib_src_compile() {
-	multilib_foreach_abi autotools-utils_src_compile "${@}"
+	if declare -f autotools_compile >/dev/null; then
+		multilib_foreach_abi \
+			_autotools-utils_run_phase autotools_compile "${@}"
+	else
+		multilib_foreach_abi \
+			_autotools-utils_run_phase \
+			autotools-utils_autotools_compile "${@}"
+	fi
 }
 
 autotools-multilib_src_test() {
-	multilib_foreach_abi autotools-utils_src_test "${@}"
+	if declare -f autotools_test >/dev/null; then
+		multilib_foreach_abi \
+			_autotools-utils_run_phase autotools_test "${@}"
+	else
+		multilib_foreach_abi \
+			_autotools-utils_run_phase \
+			autotools-utils_autotools_test "${@}"
+	fi
 }
 
 autotools-multilib_src_install() {
-	autotools-multilib_secure_install() {
-		autotools-utils_src_install "${@}"
+	_autotools-multilib_wrap_install() {
+		"${@}"
 
 		multilib_prepare_wrappers
 		# Make sure all headers are the same for each ABI.
 		multilib_check_headers
 	}
 
-	multilib_foreach_abi autotools-multilib_secure_install "${@}"
+	if declare -f autotools_install >/dev/null; then
+		multilib_foreach_abi _autotools-multilib_wrap_install \
+			_autotools-utils_run_phase autotools_install "${@}"
+	else
+		multilib_foreach_abi _autotools-multilib_wrap_install \
+			_autotools-utils_run_phase \
+			autotools-utils_autotools_install "${@}"
+	fi
+
+	if declare -f autotools_install_all >/dev/null; then
+		_autotools-utils_run_phase autotools_install_all "${@}"
+	else
+		_autotools-utils_run_phase \
+			autotools-utils_autotools_install_all "${@}"
+	fi
 
 	# merge the wrappers
 	multilib_install_wrappers
diff --git a/gx86/eclass/autotools-utils.eclass b/gx86/eclass/autotools-utils.eclass
index e6bf526..b0a299c 100644
--- a/gx86/eclass/autotools-utils.eclass
+++ b/gx86/eclass/autotools-utils.eclass
@@ -14,8 +14,15 @@
 # handling, libtool files removal.
 #
 # Please note that autotools-utils does not support mixing of its phase
-# functions with regular econf/emake calls. If necessary, please call
-# autotools-utils_src_compile instead of the latter.
+# functions with regular econf/emake calls in src_*. If necessary, please
+# declare autotools_* sub-phases instead which will be run in ${BUILD_DIR}.
+#
+# autotools-utils uses the following sub-phases:
+#
+# - autotools_prepare_all, autotools_install_all -- run in ${S}, once.
+#
+# - autotools_configure, autotools_compile, autotools_test,
+#   autotools_install -- run in ${BUILD_DIR}, may be run multiple times.
 #
 # @EXAMPLE:
 # Typical ebuild using autotools-utils.eclass:
@@ -60,26 +67,26 @@
 # 	"${FILESDIR}/${P}-unbundle_libpng.patch"
 # )
 #
-# src_configure() {
+# autotools_configure() {
 # 	local myeconfargs=(
 # 		$(use_enable debug)
 # 		$(use_with qt4)
 # 		$(use_enable threads multithreading)
 # 		$(use_with tiff)
 # 	)
-# 	autotools-utils_src_configure
+# 	edefault
 # }
 #
-# src_compile() {
-# 	autotools-utils_src_compile
-# 	use doc && autotools-utils_src_compile docs
+# autotools_compile() {
+# 	edefault
+# 	use doc && emake docs
 # }
 #
-# src_install() {
-# 	use doc && HTML_DOCS=("${BUILD_DIR}/apidocs/html/")
-# 	autotools-utils_src_install
+# autotools_install_all() {
+# 	use doc && HTML_DOCS=( apidocs/html/. )
+# 	edefault
 # 	if use examples; then
-# 		dobin "${BUILD_DIR}"/foo_example{1,2,3} \\
+# 		dobin foo_example{1,2,3} \\
 # 			|| die 'dobin examples failed'
 # 	fi
 # }
@@ -228,6 +235,8 @@ _check_build_dir() {
 	# Backwards compatibility for getting the value.
 	AUTOTOOLS_BUILD_DIR=${BUILD_DIR}
 	echo ">>> Working in BUILD_DIR: \"${BUILD_DIR}\""
+
+	mkdir -p "${BUILD_DIR}" || die
 }
 
 # @FUNCTION: remove_libtool_files
@@ -383,12 +392,12 @@ autotools-utils_autoreconf() {
 	done
 }
 
-# @FUNCTION: autotools-utils_src_prepare
+# @FUNCTION: autotools-utils_autotools_prepare_all
 # @DESCRIPTION:
 # The src_prepare function.
 #
 # Supporting PATCHES array and user patches. See base.eclass(5) for reference.
-autotools-utils_src_prepare() {
+autotools-utils_autotools_prepare_all() {
 	debug-print-function ${FUNCNAME} "$@"
 
 	local want_autoreconf=${AUTOTOOLS_AUTORECONF}
@@ -415,7 +424,7 @@ autotools-utils_src_prepare() {
 	elibtoolize --patch-only
 }
 
-# @FUNCTION: autotools-utils_src_configure
+# @FUNCTION: autotools-utils_autotools_configure
 # @DESCRIPTION:
 # The src_configure function. For out of source build it creates build
 # directory and runs econf there. Configuration parameters defined
@@ -424,7 +433,7 @@ autotools-utils_src_prepare() {
 #
 # IUSE="static-libs" passes --enable-shared and either --disable-static/--enable-static
 # to econf respectively.
-autotools-utils_src_configure() {
+autotools-utils_autotools_configure() {
 	debug-print-function ${FUNCNAME} "$@"
 
 	[[ -z ${myeconfargs+1} || $(declare -p myeconfargs) == 'declare -a'* ]] \
@@ -435,7 +444,6 @@ autotools-utils_src_configure() {
 	# Common args
 	local econfargs=()
 
-	_check_build_dir
 	if "${ECONF_SOURCE}"/configure --help 2>&1 | grep -q '^ *--docdir='; then
 		econfargs+=(
 			--docdir="${EPREFIX}"/usr/share/doc/${PF}
@@ -453,40 +461,38 @@ autotools-utils_src_configure() {
 	# Append user args
 	econfargs+=("${myeconfargs[@]}")
 
-	mkdir -p "${BUILD_DIR}" || die
-	pushd "${BUILD_DIR}" > /dev/null || die
 	econf "${econfargs[@]}" "$@"
-	popd > /dev/null || die
 }
 
-# @FUNCTION: autotools-utils_src_compile
+# @FUNCTION: autotools-utils_autotools_compile
 # @DESCRIPTION:
 # The autotools src_compile function, invokes emake in specified BUILD_DIR.
-autotools-utils_src_compile() {
+autotools-utils_autotools_compile() {
 	debug-print-function ${FUNCNAME} "$@"
 
-	_check_build_dir
-	pushd "${BUILD_DIR}" > /dev/null || die
 	emake "$@" || die 'emake failed'
-	popd > /dev/null || die
 }
 
-# @FUNCTION: autotools-utils_src_install
+# @FUNCTION: autotools-utils_autotools_install
+# @DESCRIPTION:
+# The build-dir part of src_install function. Runs emake install.
+autotools-utils_autotools_install() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	emake DESTDIR="${D}" "$@" install || die "emake install failed"
+}
+
+# @FUNCTION: autotools-utils_autotools_install_all
 # @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
+# The common part of autotools src_install function. 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() {
+autotools-utils_autotools_install_all() {
 	debug-print-function ${FUNCNAME} "$@"
 
-	_check_build_dir
-	pushd "${BUILD_DIR}" > /dev/null || die
-	emake DESTDIR="${D}" "$@" install || die "emake install failed"
-	popd > /dev/null || die
-
 	# Move docs installed by autotools (in EAPI < 4).
 	if [[ ${EAPI} == [23] ]] \
 			&& path_exists "${D}${EPREFIX}"/usr/share/doc/${PF}/*; then
@@ -532,17 +538,88 @@ autotools-utils_src_install() {
 	prune_libtool_files ${prune_ltfiles:+--${prune_ltfiles}}
 }
 
-# @FUNCTION: autotools-utils_src_test
+# @FUNCTION: autotools-utils_autotools_test
 # @DESCRIPTION:
 # The autotools src_test function. Runs emake check in build directory.
-autotools-utils_src_test() {
+autotools-utils_autotools_test() {
 	debug-print-function ${FUNCNAME} "$@"
 
-	_check_build_dir
-	pushd "${BUILD_DIR}" > /dev/null || die
-
 	# XXX: do we need to support other targets in autotools?
 	emake check "${@}" || die 'emake check failed.'
+}
+
+# @FUNCTION: _autotools-utils_run_phase
+# @USAGE: <sub-phase> [<args>...]
+# @INTERNAL
+# @DESCRIPTION:
+# Run the given ebuild sub-phase or the default implementation.
+_autotools-utils_run_phase() {
+	local phase=${1}
+
+	# it's ok to have wrong value in default impls
+	# since they can't use it anyway.
+	eval "edefault() { autotools-utils_${phase} \"\${@}\"; }"
+	if [[ ${phase} != *_all ]]; then
+		_check_build_dir
+		pushd "${BUILD_DIR}" > /dev/null || die
+	fi
+
+	"${@}"
+
+	if [[ ${phase} != *_all ]]; then
+		popd > /dev/null || die
+	fi
+	unset -f edefault
+}
+
+autotools-utils_src_prepare() {
+	if declare -f autotools_prepare_all >/dev/null; then
+		_autotools-utils_run_phase autotools_prepare_all "${@}"
+	else
+		_autotools-utils_run_phase \
+			autotools-utils_autotools_prepare_all "${@}"
+	fi
+}
+
+autotools-utils_src_configure() {
+	if declare -f autotools_configure >/dev/null; then
+		_autotools-utils_run_phase autotools_configure "${@}"
+	else
+		_autotools-utils_run_phase \
+			autotools-utils_autotools_configure "${@}"
+	fi
+}
+
+autotools-utils_src_compile() {
+	if declare -f autotools_compile >/dev/null; then
+		_autotools-utils_run_phase autotools_compile "${@}"
+	else
+		_autotools-utils_run_phase \
+			autotools-utils_autotools_compile "${@}"
+	fi
+}
+
+autotools-utils_src_test() {
+	if declare -f autotools_test >/dev/null; then
+		_autotools-utils_run_phase autotools_test "${@}"
+	else
+		_autotools-utils_run_phase \
+			autotools-utils_autotools_test "${@}"
+	fi
+}
 
-	popd > /dev/null || die
+autotools-utils_src_install() {
+	if declare -f autotools_install >/dev/null; then
+		_autotools-utils_run_phase autotools_install "${@}"
+	else
+		_autotools-utils_run_phase \
+			autotools-utils_autotools_install "${@}"
+	fi
+
+	if declare -f autotools_install_all >/dev/null; then
+		_autotools-utils_run_phase autotools_install_all "${@}"
+	else
+		_autotools-utils_run_phase \
+			autotools-utils_autotools_install_all "${@}"
+	fi
 }
-- 
1.8.2.1

Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Michał Górny]

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

On Thu, 2 May 2013 14:26:11 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> I've thought for a bit and got the conclusion that the best solution
> for quite an irritating syntax of autotools-multilib is to use
> sub-phase functions. To increase consistency between ebuilds, the same
> phases can be used in autotools-utils directly.

For example, the alsa-lib ebuild could be changed like the following:

Index: alsa-lib-1.0.27-r3.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/media-libs/alsa-lib/alsa-lib-1.0.27-r3.ebuild,v
retrieving revision 1.1
diff -u -B -r1.1 alsa-lib-1.0.27-r3.ebuild
--- alsa-lib-1.0.27-r3.ebuild	3 May 2013 14:38:28 -0000	1.1
+++ alsa-lib-1.0.27-r3.ebuild	4 May 2013 07:26:08 -0000
@@ -4,9 +4,11 @@
 
 EAPI=5
 
+AUTOTOOLS_AUTORECONF=1
+AUTOTOOLS_PRUNE_LIBTOOL_FILES=all
 PYTHON_COMPAT=( python2_7 )
 
-inherit autotools eutils multilib multilib-minimal python-single-r1
+inherit autotools-multilib multilib python-single-r1
 
 DESCRIPTION="Advanced Linux Sound Architecture Library"
 HOMEPAGE="http://www.alsa-project.org/"
@@ -27,47 +29,47 @@
 	use python && python-single-r1_pkg_setup
 }
 
-src_prepare() {
+autotools_prepare_all() {
 	# dlclose, pcm, kernel, inline, inline-2 are all from upstream
-	epatch \
+	local PATCHES=(
 		"${FILESDIR}"/1.0.25-extraneous-cflags.diff \
 		"${FILESDIR}"/${P}-{dlclose,pcm,kernel}.patch \
 		"${FILESDIR}"/${P}-inline{,-2}.patch
+	)
 
 	sed -i -e 's:AM_CONFIG_HEADER:AC_CONFIG_HEADERS:' configure.in || die #466980
 
-	epatch_user
-
-	eautoreconf
 	# if eautoreconf'd with recent autoconf, then epunt_cxx is
 	# unncessary wrt #460974
 #	epunt_cxx
+
+	edefault
 }
 
-multilib_src_configure() {
-	local myconf
+autotools_configure() {
+	local myeconfargs=(
+		--enable-shared
+		--disable-resmgr
+		--enable-rawmidi
+		--enable-seq
+		--enable-aload
+		$(use_with debug)
+		$(use_enable alisp)
+	)
+
 	# enable Python only on final ABI
 	if [[ ${ABI} == ${DEFAULT_ABI} ]]; then
-		myconf="$(use_enable python)"
+		myeconfargs+=( $(use_enable python) )
 	else
-		myconf="--disable-python"
+		myeconfargs+=( --disable-python )
 	fi
-	use elibc_uclibc && myconf+=" --without-versioned"
+	use elibc_uclibc && myeconfargs+=( --without-versioned )
 
-	ECONF_SOURCE=${S} \
-	econf \
-		--enable-shared \
-		--disable-resmgr \
-		--enable-rawmidi \
-		--enable-seq \
-		--enable-aload \
-		$(use_with debug) \
-		$(use_enable alisp) \
-		${myconf}
+	edefault
 }
 
-multilib_src_compile() {
-	emake
+autotools_compile() {
+	edefault
 
 	if [[ ${ABI} == ${DEFAULT_ABI} ]] && use doc; then
 		emake doc
@@ -76,15 +78,9 @@
 	fi
 }
 
-multilib_src_install() {
-	emake DESTDIR="${D}" install
+autotools_install() {
+	edefault
 	if [[ ${ABI} == ${DEFAULT_ABI} ]] && use doc; then
 		dohtml -r doc/doxygen/html/.
 	fi
 }
-
-multilib_src_install_all() {
-	prune_libtool_files --all
-	find "${ED}"/usr/$(get_libdir)/alsa-lib -name '*.a' -exec rm -f {} +
-	dodoc ChangeLog TODO
-}


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Greg Turner]

On Thu, May 2, 2013 at 5:26 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Hi,
>
> I've thought for a bit and got the conclusion that the best solution
> for quite an irritating syntax of autotools-multilib is to use
> sub-phase functions.

Sorry for the delayed response, but having been playing with this
stuff lately, and I'd like to state for the record that I
whole-heartedly endorse this product and/or service.

>   autotools_configure()
>   autotools_install()
>   autotools_install_all()

I like that you manage to avoid syntax like:

  autotools_multilib_${phase}_${applicability-specifier}_${etc}...

:)

The name of the game is to get from where we are now, to where we want
to be (presumably, a future in which we can rm -rf
${PORTDIR}/app-emulation/emul-linux-x86-*), with a minimum of
repetitive and/or difficult retrofit labor.

Ideally, to multilib-retrofit an ebuild, the ebuild-repair-person
would just chop up the code a bit, and indicate to the framework which
snippets pertain to which ABI's or are ABI-independent.

We're nowhere near that now.  As you suggest, the problem is that
there's no way to "hook" any per-ABI script code into the
autotools-multilib phase functions without copy pasting the whole
boilerplate, which shrinks the value-proposition of autotools-multilib
(vs. direct inheritance to multilib-build) down to almost nothing.

All but the most simple pre-USE_EXPAND-abi-ebuilds have snippets of
script code that want to run on a per-ABI basis, often inconveniently
interspersed between src_prepare() and src_configure(), and there is
no low-effort way to wedge that code into the autotools-multilib
framework as implemented.

Often, there is some clever substitution that can be made to bridge
this feature-gap -- but by now the ebuild-repair-person is well into
"investigating/thinking deeply/drawing-board" mode, precisely where he
doesn't want to find himself if he's trying to quickly blow through a
deeply-entangled batch of 50 or 100 ebuilds requiring simultaneous
retrofitting.

> While this seems rather cosmetic...

It's not just a cosmetic problem.  ... but, a brief diversion about
aesthetics: I think, in ebuild-writing, there's a fine line between
cosmetically fucked and just plain fucked.  Likewise, the converse
also holds: an aesthetically blessed ebuild is probably blessed for
developers, bugzilla worker-bees, and end-users (gentoo sysadmins)
alike.

So, in short, cosmetic improvements are good and intrinsically
important.  Furthermore, the term "cosmetic" has connotations of
"ineffectual": that is not the case here, there are real practical
problems being solved -- your proposal ENABLES the
ebuild-repair-person to shuffle around code in a seemingly trivial
manner, but that's NOT an option with the current implementation,
instead the ebuild-repair-person must struggle against the limitations
of the framework (in addition to figuring out whatever true semantic
change is required by the retrofit).

Anyhow, meanwhile, back on planet Earth...

> The sub-phases without '_all' suffix are run inside BUILD_DIR, and
> repeated for each multilib ABI. The sub-phases with '_all' are always
> run only once, and inside S.

It's clearly a move in the right direction.  New choke points would
probably reveal themselves once we were freed from the tyranny of
constantly typing in the same code over and over :)

I do think "all" vs. "" is dsylexia-inducing and should be changed... perhaps:

at_${phase}_abi: per-abi steps (i.e., probably in per-abi ${BUILD_DIR})
at_${phase}: global steps (i.e., in ${S})

s/at/autotools/ obv.... or just leave it!  short==good here.

Anyhow, those really are trivial semantic matters.

I also think your proposal could go a bit further in the ability to
slice-and-dice the sub-phase functions.  For example, there might be
uses for granularity like:

at_${phase}: as before

at_${phase}_all: as before

at_${phase}_${ABI}: single-abi-specific stuff executed before
at_${phase}, i.e., platform-specific configure tweaks

at_${phase}_best: stuff that needs to happen in ${BUILD_DIR}, but
should only happen for DEFAULT_ABI, i.e.:, compile documentation from
source, full emake installs to deploy unwrapped header files and
/usr/share/doc stuff, etc.

Cross-compile support might suggest a couple of additional sub-phases
(i.e.: a sub-phase to generate ${CBUILD}-targeted intermediate tools
(perhaps only during cross-compiles, but I really wish somehow that
could be coded just once, tagged, and the framework could decide
whether to do anything unusual with it based on context.

> What are your thoughts? The patch is sent in reply to this mail.

Just saw your message that you are abandoning this proposal due to
lack of interest.  I think the lack of comments is not particularly
surprising.  How many people are actively getting their hands dirty
attempting to mass-retrofit ebuilds for USE_EXPAND abi-based multilib?
 I'd wager you're the only one, unless you want to count me over the
last 24 hours or so but I'm just dabbling and will probably lose
interest.

In other words, probably you are the only person in a position to see
what the requirements are.  If you are concerned about building stuff
with no "eyeballs" / feedback, then put them in new eclasses instead
of fixing the old ones (it's 'prolly better for back-compatibility to
do so anyhow).  But I'm 100% convinced you're on the right track
because I was about to start building what you described myself (and
I'm /never/ wrong! hahaha, ok, far from it, but as they say, "even if
I do say so myself...")

-gmt

Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Michał Górny]

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

Dnia 2013-09-23, o godz. 13:59:48
Greg Turner <gmt@malth.us> napisał(a):

> > What are your thoughts? The patch is sent in reply to this mail.  
> 
> Just saw your message that you are abandoning this proposal due to
> lack of interest.  I think the lack of comments is not particularly
> surprising.  How many people are actively getting their hands dirty
> attempting to mass-retrofit ebuilds for USE_EXPAND abi-based multilib?
>  I'd wager you're the only one, unless you want to count me over the
> last 24 hours or so but I'm just dabbling and will probably lose
> interest.

We have four active Gentoo developers in the team and one very helpful
user. Plus a number of developers who are working in their narrow areas
and supporting us indirectly. That's more than I expected,
and the project has bright future. There are a few people who just like
to trip us up but I think it'll all end up well in the end.

As for this particular idea, I plan to make autotools-multilib use
multilib-minimal and therefore inherit its phase functions. However,
I'm still waiting for bug #485046 [1] to be resolved.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=485046

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Greg Turner]

On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny <mgorny@gentoo.org> wrote:
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=485046

Hey, that looks familiar... same basic problem exists in bzip2[static]
src_compile:

https://bugs.gentoo.org/show_bug.cgi?id=485690

Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Greg Turner]

On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny <mgorny@gentoo.org> wrote:
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=485046

Hey, that looks familiar... same basic problem exists in bzip2[static]
src_compile:

https://bugs.gentoo.org/show_bug.cgi?id=485690

Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Greg Turner]

On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> We have four active Gentoo developers in the team and one very helpful
> user. Plus a number of developers who are working in their narrow areas
> and supporting us indirectly. That's more than I expected,
> and the project has bright future. There are a few people who just like
> to trip us up but I think it'll all end up well in the end.

Is there a work-in-progress code repository somewhere?  Mailing list?
If I'm going to keep hacking on this I should definitely sync up with
you guys, I have a growing number of offline patches (some of which
might be good enough to go in as-is, some needing some work, and a few
abominations).

-gmt

Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Michał Górny]

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

Dnia 2013-09-24, o godz. 01:40:58
Greg Turner <gmt@malth.us> napisał(a):

> On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny <mgorny@gentoo.org> wrote:
> >
> > We have four active Gentoo developers in the team and one very helpful
> > user. Plus a number of developers who are working in their narrow areas
> > and supporting us indirectly. That's more than I expected,
> > and the project has bright future. There are a few people who just like
> > to trip us up but I think it'll all end up well in the end.
> 
> Is there a work-in-progress code repository somewhere?  Mailing list?
> If I'm going to keep hacking on this I should definitely sync up with
> you guys, I have a growing number of offline patches (some of which
> might be good enough to go in as-is, some needing some work, and a few
> abominations).

Not really, most of the code goes into gx86 directly. Some of it gets
masked first (like the late OpenGL batch). We can be reached through
multilib@gentoo.org. If you prefer IRC, you're looking for mgorny,
pacho2, aballier, _AxS_, iamnr3.

-- 
Best regards,
Michał Górny

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