[gentoo-dev] New eclass: autotools-multilib-minimal

[gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

Some people seem to feel uncomfortable with autotools-multilib, because
it depends on autotools-utils.

Instead of arguing whether it makes sense or not I'd propose a similar
autotools related eclass.

I also attach an example conversion of media-libs/libexif (the
maintainer wants to keep the changes minimal).
Effectively I am only (almost) changing the function names and not the
ebuild code.

Feel free to propose a different eclass name.

[-- Attachment #2: autotools-multilib-minimal.eclass --]
[-- Type: text/plain, Size: 3010 bytes --]

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

# @ECLASS: autotools-multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald <hasufell@gentoo.org>
# @BLURB: wrapper for multilib builds providing convenient multilib_src_* functions
# @DESCRIPTION:
#
# src_configure, src_compile, src_test and src_install are exported
# use multilib_src_* instead of src_* which runs this phase for
# all enabled ABIs
#
# if you need generic install rules, use multilib_src_install_all function

# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set to enable in-source build.
# If you enable this, ensure that prepabisources is called
# at the END of src_prepare!


# EAPI=5 is required for meaningful MULTILIB_USEDEP.
case ${EAPI:-0} in
	5) ;;
	*) die "EAPI=${EAPI} is not supported" ;;
esac

inherit multilib-build

EXPORT_FUNCTIONS src_configure src_compile src_test src_install

prepabisources() {
	if [[ $AUTOTOOLS_IN_SOURCE_BUILD ]] ; then
		einfo "Copying sources to abi-specific dirs"

		prepabisources() {
			cp -pR "${S}" "${BUILD_DIR}" || die "failed to copy sources"
		}
		multilib_foreach_abi prepabisources
	fi
}

autotools-multilib-minimal_src_configure() {
	local myeconfsource
	if [[ $AUTOTOOLS_IN_SOURCE_BUILD ]] ; then
		myeconfsource=.
	else
		myeconfsource="${S}"
	fi

	_autotools-multilib-minimal_src_configure() {
		einfo "Configuring for ${ABI}"

		mkdir -p "${BUILD_DIR}" || die
		pushd "${BUILD_DIR}" >/dev/null || die
		if declare -f multilib_src_configure >/dev/null ; then
			ECONF_SOURCE="${myeconfsource}" multilib_src_configure
		else
			ECONF_SOURCE="${myeconfsource}" default_src_configure
		fi
		popd >/dev/null || die
	}
	multilib_foreach_abi _autotools-multilib-minimal_src_configure
}

autotools-multilib-minimal_src_compile() {
	_autotools-multilib-minimal_src_compile() {
		einfo "Compiling for ${ABI}"

		pushd "${BUILD_DIR}" >/dev/null || die
		if declare -f multilib_src_compile >/dev/null ; then
			multilib_src_compile
		else
			default_src_compile
		fi
		popd >/dev/null || die
	}
	multilib_foreach_abi _autotools-multilib-minimal_src_compile
}

autotools-multilib-minimal_src_test() {
	_autotools-multilib-minimal_src_test() {
		einfo "Testing for ${ABI}"

		pushd "${BUILD_DIR}" >/dev/null || die
		if declare -f multilib_src_test >/dev/null ; then
			multilib_src_test
		else
			default_src_test
		fi
		popd >/dev/null || die
	}
	multilib_foreach_abi _autotools-multilib-minimal_src_test
}

autotools-multilib-minimal_src_install() {
	_autotools-multilib-minimal_src_install() {
		einfo "Installing for ${ABI}"

		pushd "${BUILD_DIR}" >/dev/null || die
		if declare -f multilib_src_install >/dev/null ; then
			multilib_src_install
		else
			default_src_install	
		fi
		multilib_check_headers
		popd >/dev/null || die
	}
	multilib_foreach_abi _autotools-multilib-minimal_src_install

	if declare -f multilib_src_install_all >/dev/null ; then
		multilib_src_install_all
	fi
}

[-- Attachment #3: libexif-0.6.21.ebuild.diff --]
[-- Type: text/plain, Size: 1438 bytes --]

--- media-libs/libexif/libexif-0.6.21.ebuild
+++ media-libs/libexif/libexif-0.6.21-r1.ebuild
@@ -2,8 +2,8 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/media-libs/libexif/libexif-0.6.21.ebuild,v 1.8 2012/11/07 19:03:58 grobian Exp $
 
-EAPI=4
-inherit eutils libtool
+EAPI=5
+inherit autotools-multilib-minimal eutils libtool
 
 DESCRIPTION="Library for parsing, editing, and saving EXIF data"
 HOMEPAGE="http://libexif.sourceforge.net/"
@@ -11,7 +11,7 @@
 
 LICENSE="LGPL-2.1"
 SLOT="0"
-KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~x64-solaris ~x86-solaris"
+KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~x64-solaris ~x86-solaris"
 IUSE="doc nls static-libs"
 
 RDEPEND="nls? ( virtual/libintl )"
@@ -26,7 +26,7 @@
 	elibtoolize # For *-bsd
 }
 
-src_configure() {
+multilib_src_configure() {
 	econf \
 		$(use_enable static-libs static) \
 		$(use_enable nls) \
@@ -34,8 +34,11 @@
 		--with-doc-dir="${EPREFIX}"/usr/share/doc/${PF}
 }
 
-src_install() {
+multilib_src_install() {
 	emake DESTDIR="${D}" install
+}
+
+multilib_src_install_all() {
 	prune_libtool_files
 	rm -f "${ED}"/usr/share/doc/${PF}/{ABOUT-NLS,COPYING}
 }

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

Before people start asking I should explain why I started this:
https://bugs.gentoo.org/show_bug.cgi?id=458638

I think having such an eclass has several advantages over
autootools-multilib.eclass (which depends on autotools-utils.eclass) as
it is now:

a) Less eclass dependencies. One could argue: the more eclasses my
ebuild uses the more prone to error and exposed to changes it is.
b) easier conversion in some cases: often times a simple rename
src_compile -> multilib_src_compile will do
c) it allows more custom definition of phase functions
d) the previous point will also allow to convert go-mono.eclass packages
without introducing yet another eclass for that
e) autotools-utils.eclass does a bit more than just calling default
phase functions; the developer has little choice on this matter unless
he wants to rewrite his ebuild based on multilib-build.eclass which will
create a lot of code duplication in ebuilds, hence this proposition

I don't have a problem with the present eclasses, but I find this a
logical enhancement.

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Michał Górny]

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

On Sun, 24 Feb 2013 05:22:43 +0100
hasufell <hasufell@gentoo.org> wrote:

> Before people start asking I should explain why I started this:
> https://bugs.gentoo.org/show_bug.cgi?id=458638
> 
> I think having such an eclass has several advantages over
> autootools-multilib.eclass (which depends on autotools-utils.eclass) as
> it is now:
> 
> a) Less eclass dependencies. One could argue: the more eclasses my
> ebuild uses the more prone to error and exposed to changes it is.
> b) easier conversion in some cases: often times a simple rename
> src_compile -> multilib_src_compile will do
> c) it allows more custom definition of phase functions
> d) the previous point will also allow to convert go-mono.eclass packages
> without introducing yet another eclass for that

Then don't put 'autotools' in the name.

> e) autotools-utils.eclass does a bit more than just calling default
> phase functions; the developer has little choice on this matter unless
> he wants to rewrite his ebuild based on multilib-build.eclass which will
> create a lot of code duplication in ebuilds, hence this proposition

Yes, everyone sees 'a bit more' but nobody so far was able to point
what it is exactly. Or people simply don't know what PMS does nowadays.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Diego Elio Pettenò]

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

On 24/02/2013 11:06, Michał Górny wrote:
> Then don't put 'autotools' in the name.

+1

> Yes, everyone sees 'a bit more' but nobody so far was able to point
> what it is exactly. Or people simply don't know what PMS does nowadays.

I've been trying to get myself to use autotools-utils more often lately,
especially since I think at this point, with multilib support easier to
wire in it than others, it would be the right way to proceed with (it's
going to be a ruddy mess with orthogonal ABIs such as Ruby's but I don't
want to go there right now).

The only thing that would upset me in all of this is something that is
unfortunately needed for multilib builds to not be completely idiotic,
and that is the out-of-source builds. I had to fix one package for that
already (lksctp-tools).

On the other hand I usually fixed that stuff anyway because I use
out-of-source builds when I'm developing them so...

Btw, I know I've been more than rough on Michał before, so I guess I'd
better say this out loud: I really like his roadmap toward multilib
support. Kudos!

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
> On 24/02/2013 11:06, Michał Górny wrote:
>> Then don't put 'autotools' in the name.
> 
> +1
> 

That would be multilib-minimal.eclass then?

I find that name silly, but I don't have a better idea.


ABCD also suggested something else:
autotools-multilib.eclass -> autotools-utils-multilib.eclass
autotools-multilib-minimal.eclass -> autotools-multilib.eclass

that is more logical imo, but would maybe cause unnecessary hassle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKiEPAAoJEFpvPKfnPDWzF+UIAJ13DlLh6dIfY9zvbd9v3z48
7jiW9z/aeiEWYxy9KxM5zLRfosnNPGNbUiTjiozVq1gLFA4anJiEDO86iSaQIYJa
Uv5CoSNF7MZXFMEmNk0GoJqLQmzrhFyxYF27rqc+yt0B+unOcBlZ34DsUTJXTzQF
CxZY7QKiLonN35zPK72uJxaAW12i+/0YDlgU/Sji7cO57JXW23nA7Gue7pBY6ACm
rQi/aTzj2TEe+mWPoWFLgwPfk3EYeLPVev9ouVJMW6CHJRlf1gX6giVpMFnQQNfm
TgfCYvQaVYgh+oaKzmz5Kg9xu0NdhdA5GQI8SEcf658sNYXj3/dco0oVJIF3DgI=
=BHkt
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Pacho Ramos]

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

El dom, 24-02-2013 a las 15:17 +0100, hasufell escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
> > On 24/02/2013 11:06, Michał Górny wrote:
> >> Then don't put 'autotools' in the name.
> > 
> > +1
> > 
> 
> That would be multilib-minimal.eclass then?
> 
> I find that name silly, but I don't have a better idea.
> 

Probably multilib-build-minimal.eclass :/



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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Michał Górny]

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

On Sun, 24 Feb 2013 05:22:43 +0100
hasufell <hasufell@gentoo.org> wrote:

> Before people start asking I should explain why I started this:
> https://bugs.gentoo.org/show_bug.cgi?id=458638
> 
> I think having such an eclass has several advantages over
> autootools-multilib.eclass (which depends on autotools-utils.eclass) as
> it is now:

You wanted the other points, so here you go.

> a) Less eclass dependencies. One could argue: the more eclasses my
> ebuild uses the more prone to error and exposed to changes it is.

That's as good as bundling libraries. Really.

> b) easier conversion in some cases: often times a simple rename
> src_compile -> multilib_src_compile will do

Easy != good. The eclass switch is a good point to fix bugs which
should have been fixed long ago. By making it unnecessary, you just
keep those bugs live and hidden.

> c) it allows more custom definition of phase functions

More custom than what?

> d) the previous point will also allow to convert go-mono.eclass packages
> without introducing yet another eclass for that

So you're introducing a hacky eclass just because you're too lazy to
convert go-mono packages properly and too impatient to let others do
the work properly for you?

> e) autotools-utils.eclass does a bit more than just calling default
> phase functions; the developer has little choice on this matter unless
> he wants to rewrite his ebuild based on multilib-build.eclass which will
> create a lot of code duplication in ebuilds, hence this proposition

And as I already told you, this argument just proves that you don't
know the eclass in question and just throwing random accusations.

> I don't have a problem with the present eclasses, but I find this a
> logical enhancement.

If that's logical, then please provide a graph showing where it
logically fits. Because so far, it's either hate-built redundant eclass
or quick draft eclass written for a single package.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

On 02/24/2013 03:57 PM, Michał Górny wrote:
> On Sun, 24 Feb 2013 05:22:43 +0100 hasufell <hasufell@gentoo.org>
> wrote:
> 
>> Before people start asking I should explain why I started this: 
>> https://bugs.gentoo.org/show_bug.cgi?id=458638
>> 
>> I think having such an eclass has several advantages over 
>> autootools-multilib.eclass (which depends on
>> autotools-utils.eclass) as it is now:
> 
> You wanted the other points, so here you go.
> 
>> a) Less eclass dependencies. One could argue: the more eclasses
>> my ebuild uses the more prone to error and exposed to changes it
>> is.
> 
> That's as good as bundling libraries. Really.

That analogy is flawed. It's about ebuild design and the fact that I
don't just convert my ebuild to _multilib_, but also to
_autotools-utils_, so I have to keep an eye on another provider.

> 
>> b) easier conversion in some cases: often times a simple rename 
>> src_compile -> multilib_src_compile will do
> 
> Easy != good. The eclass switch is a good point to fix bugs which 
> should have been fixed long ago. By making it unnecessary, you
> just keep those bugs live and hidden.
> 
>> c) it allows more custom definition of phase functions
> 
> More custom than what?

Than autotools-multilib.eclass.

> 
>> d) the previous point will also allow to convert go-mono.eclass
>> packages without introducing yet another eclass for that
> 
> So you're introducing a hacky eclass just because you're too lazy
> to convert go-mono packages properly and too impatient to let
> others do the work properly for you?

Please point out where the eclass is hacky. I haven't heard a
technical argument against it despite that you think
autotools-multilib.eclass is better.
That might be true, but then I don't understand why people refuse to
use it which is the only reason I am proposing this.

Also, I am not too lazy to convert go-mono packages. I have already
written the go-mono-multilib.eclass and it looks almost the same as
autotools-multilib-minimal.eclass, so I am wondering why I want
code-duplication in eclasses.

> 
>> e) autotools-utils.eclass does a bit more than just calling
>> default phase functions; the developer has little choice on this
>> matter unless he wants to rewrite his ebuild based on
>> multilib-build.eclass which will create a lot of code duplication
>> in ebuilds, hence this proposition
> 
> And as I already told you, this argument just proves that you
> don't know the eclass in question and just throwing random
> accusations.
> 

No, I was just rephrasing other peoples concerns.

>> I don't have a problem with the present eclasses, but I find this
>> a logical enhancement.
> 
> If that's logical, then please provide a graph showing where it 
> logically fits. Because so far, it's either hate-built redundant
> eclass or quick draft eclass written for a single package.
> 

I don't understand you.
It works on more than one package.


Anyway... as I said, I don't care how this problem is solved. I only
care about the availability of 32bit libs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKi3GAAoJEFpvPKfnPDWzkW4H/3uaQ++8Rky1GKi+Tvffz45i
x+yNpPtje/gWFKjXVeWxQZfNV/tLsq1TZM0ruzixB6lO1vFD6Ql+8ZiuTrHHRvuV
at3+iT2AycSTeNs0qRUHjICOn5V6fMNQyIxJsrFS+HNEEbYfE36+S91YvN9WwHr6
Q2PDBp+3jueJXNVeZh+zdSQL4eo2fEuJ39/pa42SPbeRGGm6aw1SnhD9RYBcRZuf
GyuTOk7R+vwp55i4d7xXyb8eEDVh7uSqikb7OniNA15a7wrmpSLsfwonhZS/a3Qq
R/pQDXGm+aDDk7ZwXGCWRvGd7ARLqED5A+5yKcfyQeZ99RP6KHW8+xEwkr8M54I=
=3uKD
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Pacho Ramos]

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

El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
[...]
> > d) the previous point will also allow to convert go-mono.eclass packages
> > without introducing yet another eclass for that
> 
> So you're introducing a hacky eclass just because you're too lazy to
> convert go-mono packages properly and too impatient to let others do
> the work properly for you?

Would be nice to know what autotools-utils.eclass is doing differently
that is showing this problem with go-mono.eclass packages :/

Only one question, what is the reason for us having base.eclass and
autotools-utils.eclass? I still try to use plain ebuilds without
inheritting autotools-utils.eclass as I usually don't need it, probably
others do the same and refuse to have to inherit it only for multilib
support :/ How do you plan to solve this problem?

I would also like to hear why that people refuses to use
autotools-utils.eclass... because I don't have a strong opinion on this
topic 


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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Michał Górny]

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

On Sun, 24 Feb 2013 16:12:18 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
> [...]
> > > d) the previous point will also allow to convert go-mono.eclass packages
> > > without introducing yet another eclass for that
> > 
> > So you're introducing a hacky eclass just because you're too lazy to
> > convert go-mono packages properly and too impatient to let others do
> > the work properly for you?
> 
> Would be nice to know what autotools-utils.eclass is doing differently
> that is showing this problem with go-mono.eclass packages :/

I already told that I'm going to look at this but I have too much work
to do right now so it's going to take a longer while.

> Only one question, what is the reason for us having base.eclass and
> autotools-utils.eclass?

I think that base.eclass is silently intended for removal at some point
in the future. While we're here, we should probably mark it deprecated.

autotools-utils does a bit more -- especially by using out-of-source
builds. The major reason to use autotools-utils so far was to support
those builds.

Believe me or not, the day I took over the maintenance of it I seen
the opportunity to use out-of-source builds for multilib. Today, both
python-r1 & multilib-build were specifically designed to allow using
out-of-source builds with minimal effort.

> I still try to use plain ebuilds without
> inheritting autotools-utils.eclass as I usually don't need it, probably
> others do the same and refuse to have to inherit it only for multilib
> support :/ How do you plan to solve this problem?

You generally have two options on doing multilib builds: either using
out-of-source builds or in-source builds. If you decide on the latter,
you unnecessarily waste users' time and disk space to create two more
copies of sources. I don't think we should go this way.

If you decide on out-of-source builds, you basically need proper
src_{configure,compile,test,install} and that's what autotools-utils
does. Plus:

- prune_libtool_files in src_install() which most people want to do
  anyway, so that doesn't hurt -- and the pkg-config dep is going to
  be removed, by the patch I sent already.

- patch applying and autoreconf in src_prepare() -- which are
  completely optional, you are free to write your own src_prepare().
  If you wanted to apply patches by hand, you'd need to write
  src_prepare() anyway.

- adding libtool args for shared/static libs if IUSE=static-libs --
  which I wanted to remove but people considered it useful.

> I would also like to hear why that people refuses to use
> autotools-utils.eclass... because I don't have a strong opinion on this
> topic 

Well, the major argument was similar to yours -- why we should use
an eclass if default PMS functions work. But in the multilib case, they
do not work by design anymore.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Pacho Ramos]

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

El dom, 24-02-2013 a las 16:53 +0100, Michał Górny escribió:
> On Sun, 24 Feb 2013 16:12:18 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
> > [...]
> > > > d) the previous point will also allow to convert go-mono.eclass packages
> > > > without introducing yet another eclass for that
> > > 
> > > So you're introducing a hacky eclass just because you're too lazy to
> > > convert go-mono packages properly and too impatient to let others do
> > > the work properly for you?
> > 
> > Would be nice to know what autotools-utils.eclass is doing differently
> > that is showing this problem with go-mono.eclass packages :/
> 
> I already told that I'm going to look at this but I have too much work
> to do right now so it's going to take a longer while.
> 

In that case, sorry, I probably missed it for some reason :S

> > Only one question, what is the reason for us having base.eclass and
> > autotools-utils.eclass?
> 
> I think that base.eclass is silently intended for removal at some point
> in the future. While we're here, we should probably mark it deprecated.
> 

I agree, I though it was marked as deprecated time ago, but last time I
read it it appeared to be still "active"

[...]
> You generally have two options on doing multilib builds: either using
> out-of-source builds or in-source builds. If you decide on the latter,
> you unnecessarily waste users' time and disk space to create two more
> copies of sources. I don't think we should go this way.
> 
> If you decide on out-of-source builds, you basically need proper
> src_{configure,compile,test,install} and that's what autotools-utils
> does. Plus:
> 
> - prune_libtool_files in src_install() which most people want to do
>   anyway, so that doesn't hurt -- and the pkg-config dep is going to
>   be removed, by the patch I sent already.
> 
> - patch applying and autoreconf in src_prepare() -- which are
>   completely optional, you are free to write your own src_prepare().
>   If you wanted to apply patches by hand, you'd need to write
>   src_prepare() anyway.
> 
> - adding libtool args for shared/static libs if IUSE=static-libs --
>   which I wanted to remove but people considered it useful.
> 
> > I would also like to hear why that people refuses to use
> > autotools-utils.eclass... because I don't have a strong opinion on this
> > topic 
> 
> Well, the major argument was similar to yours -- why we should use
> an eclass if default PMS functions work. But in the multilib case, they
> do not work by design anymore.
> 

OK, thanks for the info


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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Alexis Ballier]

On Sun, 24 Feb 2013 01:34:47 +0100
hasufell <hasufell@gentoo.org> wrote:

> Some people seem to feel uncomfortable with autotools-multilib,
> because it depends on autotools-utils.

To be honest, I don't particularly like autotools-utils, I tend to
consider it a useless bloat. However, Michal's work on
autotools-multilib is IMHO the right thing to do: If you use the
autotools-utils syntax then it's trivial to support multilib without
useless duplication of code.
I still believe such an eclass as the one you propose is useful, except
it's not for autotools (at best temporary for broken autotools based
build systems): For example, I have no clue how to do multilib with
waf-based build systems without going the 'copy $S and run the usual
src_* phases in each directory for each ABI', which is what your eclass
is abstracting I think.

A.

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Alexis Ballier]

On Sun, 24 Feb 2013 16:53:02 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> - prune_libtool_files in src_install() which most people want to do
>   anyway, so that doesn't hurt -- and the pkg-config dep is going to
>   be removed, by the patch I sent already.

A bit OT but that's one of the things I consider useless there, I
usually do 'find "${D}" -name '*.la' -delete' which is more than
enough in most cases, faster and avoids calling a 90+ lines function
which may break or add a pkg-config dep.

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

On 02/24/2013 05:22 PM, Alexis Ballier wrote:
> On Sun, 24 Feb 2013 01:34:47 +0100
> hasufell <hasufell@gentoo.org> wrote:
> 
>> Some people seem to feel uncomfortable with autotools-multilib,
>> because it depends on autotools-utils.
> 
> To be honest, I don't particularly like autotools-utils, I tend to
> consider it a useless bloat. However, Michal's work on
> autotools-multilib is IMHO the right thing to do: If you use the
> autotools-utils syntax then it's trivial to support multilib without
> useless duplication of code.
> I still believe such an eclass as the one you propose is useful, except
> it's not for autotools (at best temporary for broken autotools based
> build systems): For example, I have no clue how to do multilib with
> waf-based build systems without going the 'copy $S and run the usual
> src_* phases in each directory for each ABI', which is what your eclass
> is abstracting I think.
> 
> A.
> 

I have no idea if it makes sense for this package (since it also
installs binaries), but as an example I have converted dev-libs/serd.

And yes, a rename of the eclass would probably be appropriate.

[-- Attachment #2: serd-0.18.2.ebuild.diff --]
[-- Type: text/plain, Size: 1018 bytes --]

--- dev-libs/serd/serd-0.18.2.ebuild
+++ dev-libs/serd/serd-0.18.2-r1.ebuild
@@ -2,9 +2,9 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/dev-libs/serd/serd-0.18.2.ebuild,v 1.1 2013/01/13 21:08:17 aballier Exp $
 
-EAPI=4
-
-inherit waf-utils
+EAPI=5
+AUTOTOOLS_IN_SOURCE_BUILD=1
+inherit waf-utils autotools-multilib-minimal
 
 DESCRIPTION="Library for RDF syntax which supports reading and writing Turtle and NTriples"
 HOMEPAGE="http://drobilla.net/software/serd/"
@@ -23,9 +23,10 @@
 
 src_prepare() {
 	sed -i -e 's/^.*run_ldconfig/#\0/' wscript || die
+	prepabisources
 }
 
-src_configure() {
+multilib_src_configure() {
 	waf-utils_src_configure \
 		--docdir=/usr/share/doc/${PF} \
 		$(use test && echo "--test") \
@@ -33,6 +34,14 @@
 		$(use static-libs && echo "--static")
 }
 
-src_test() {
+multilib_src_test() {
 	./waf test || die
 }
+
+multilib_src_compile() {
+	waf-utils_src_compile
+}
+
+multilib_src_install() {
+	waf-utils_src_install
+}

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Samuli Suominen]

On 24/02/13 17:53, Michał Górny wrote:
>> I still try to use plain ebuilds without
>> inheritting autotools-utils.eclass as I usually don't need it, probably
>> others do the same and refuse to have to inherit it only for multilib
>> support :/ How do you plan to solve this problem?
>
> You generally have two options on doing multilib builds: either using
> out-of-source builds or in-source builds. If you decide on the latter,
> you unnecessarily waste users' time and disk space to create two more
> copies of sources. I don't think we should go this way.
>
> If you decide on out-of-source builds, you basically need proper
> src_{configure,compile,test,install} and that's what autotools-utils
> does. Plus:
 >
 > - patch applying and autoreconf in src_prepare() -- which are
 >    completely optional, you are free to write your own src_prepare().
 >    If you wanted to apply patches by hand, you'd need to write
 >    src_prepare() anyway.

It's that "Plus" part that is my problem with autotools-multilib.eclass 
currently, it adds EXPORT_FUNCTIONS of src_prepare() from 
autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass
adds just another eclass/phase function to worry about for inherit order

>
> - prune_libtool_files in src_install() which most people want to do
>    anyway, so that doesn't hurt -- and the pkg-config dep is going to
>    be removed, by the patch I sent already.

but lacks a way to pass arguments to prune_libtool_files, like --all, 
since prune_libtool_files isn't that smart it gets it right everytime
i propably prefer to stick to manually calling it with or without --all
and well, this is not related to the multilib conversion so it shouldn't 
be executed anyway

> - adding libtool args for shared/static libs if IUSE=static-libs --
>    which I wanted to remove but people considered it useful.

if it's not related to the multilib conversion, it shouldn't be executed...

>
>> I would also like to hear why that people refuses to use
>> autotools-utils.eclass... because I don't have a strong opinion on this
>> topic
>
> Well, the major argument was similar to yours -- why we should use
> an eclass if default PMS functions work. But in the multilib case, they
> do not work by design anymore.
>

src_prepare() seems to be adequate from PMS for the multilib conversion

[gentoo-dev] Re: New eclass: autotools-multilib-minimal

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/24/2013 10:53 AM, Michał Górny wrote:
> I think that base.eclass is silently intended for removal at some
> point in the future. While we're here, we should probably mark it
> deprecated.
> 

The problem with deprecating base.eclass and telling people to use
autotools-utils.eclass instead is that base.eclass also defines a
src_prepare that is used for eclasses that support *non*-autotools
build systems, such as cmake-utils.eclass.  Requiring that support to
be copied around to each of the eclasses that currently inherits base
would allow the usual issues with copying code around.

- -- 
Jonathan Callen (abcd)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJRKlZ+AAoJELHSF2kinlg4L0UP/24ETiIoXIVS9it65p2s/YER
D/KCcgsbTMowWTrs488mQ8Vs/3T0Ij2sDuYRcOqqKEiDb6+aAeILhU3pDP9c8k7V
L8jV1RpF2nafO4dexXU9FBMd6KYvz3Vsf4JQfiHzybdBsVW9HE0vrU/lrST91tm8
irDxPfOWFMPGM3r8YD+AuQ6DlkgaMdnJnT+c9Bu5xtoGrjZ5inmSCeskQkX9zP54
wFFuwyg3+Db08r+qTHkUqnAPc1t3fSsz7X4tgQfX5btBjVgDKKYm2dsScjNmhvxg
4Wnv+A5R4QAcce3CWUOp/BXTAg6PuYBbGWZWm+5WzQstsZRRo+hiGh7buyIctdix
IRQaoNh7SRMiiV2STHJtjqz8+e28NsK16Na4PSbDM3GOYbiq+gb8dyDpvIQpzN6m
48G2dhETJpAvox6YnA6Ix9YDdoAl0Y25ynJSUajLbyQ9+rSiynIGnMT5UHFr9zaM
2zs9oXRaqO7Gj1A98nN0NwjC0U+sP7J2JidvcXbUO7YNx4exsgzUHdbrdG7gBpVd
iPHpECyrgh3uqIRS0j3bCR6WQAOBGb708hXrNj5a/ldGvYTYlLmt2Tbq+mJapZmp
uFLYrK1kwBmXj/3CSErO0Bg0lMspk8E0MnEljChdFPGYekkbPGhZKGp9EufczG+G
C5L3dv7V1Nv2AyyFiYB3
=cyEa
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: New eclass: autotools-multilib-minimal

[Michał Górny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sun, 24 Feb 2013 13:05:51 -0500
Jonathan Callen <abcd@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 02/24/2013 10:53 AM, Michał Górny wrote:
> > I think that base.eclass is silently intended for removal at some
> > point in the future. While we're here, we should probably mark it
> > deprecated.
> > 
> 
> The problem with deprecating base.eclass and telling people to use
> autotools-utils.eclass instead is that base.eclass also defines a
> src_prepare that is used for eclasses that support *non*-autotools
> build systems, such as cmake-utils.eclass.  Requiring that support to
> be copied around to each of the eclasses that currently inherits base
> would allow the usual issues with copying code around.

If something inherits base.eclass, it should stop. autotools-utils used
to do that but I removed the inherit because of base_src_unpack() which
was exported for no reason and caused trouble with VCS eclasses.

- -- 
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRKlmBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC
QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKiF4P/1L6vB7oSI5xIq6mrE82h7iW
PNPWWRt+HBrLdK0u1uI/vuoGDs5/t02osGKNES0QVWRZz+70wRn8LBGoOp6A9Lz3
wEgguRDf6ppZc23Sr6uHXdr/mvAaTJezcJiME4eKoYXtda/eyZeiV22raZUktcGq
wRXQIzTDGwyYZcmq454J5DfU7ANlYU2uCTMGwWgq8l1ObP55tpJuirKu8mLx+lH2
TOVNnZmWJfqlcjd0updTQjpI8ijlc7Dn42c/kd0P1SpiP6mn7qEGfYy2lfLJWnWh
Z4LOnstwSlw1P6W09Htl8PHcLIGK1wA5ShvQVnfocnpuCpY8MXG+SrjYAA1RkWkZ
dzPNzo8VKqR8wrI/WIqkPmrfRRqsUgx07uGiGkn2L4gkZiiM3zUMTQvqHI2oGhGl
VE1xdG0Ca5O09U8FOdVJyUD8vO9xL7Ie5r8p35G6aRXrxEnQf8tYhCqbFyu/tq8V
f7L4QY6I+Jivk1XvpAq217tdRDykl6zl9D0LmFzQTtPXq/HAJDLkS+qZg7JpZ6bz
nsEv23jHPKeZ+WYOHvShFbgTUc1q+ky4F2qG7C4KrMJl7U6WRFqjCQdiDyfxLkNT
SiQ1fzZDBSFSZZvEbDUpqjz4Aj2R7x0DZ/lUPd52U7KCeK4KBQaOHXD0hsihvG3C
NJ3qcCqQWZYW9fR2wBP/
=huwA
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Alexis Ballier]

On Sun, 24 Feb 2013 17:42:26 +0100
hasufell <hasufell@gentoo.org> wrote:

[...]
> I have no idea if it makes sense for this package (since it also
> installs binaries), but as an example I have converted dev-libs/serd.

yes, that's the kind of usage of your eclass I was thinking about :)
(it might make sense to convert it but there is no need for it I know
about, there might arise some commercial binary-only package using it
some day)

> And yes, a rename of the eclass would probably be appropriate.

+1

Alexis.

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Michał Górny]

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

On Sun, 24 Feb 2013 18:58:08 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 24/02/13 17:53, Michał Górny wrote:
> >> I still try to use plain ebuilds without
> >> inheritting autotools-utils.eclass as I usually don't need it, probably
> >> others do the same and refuse to have to inherit it only for multilib
> >> support :/ How do you plan to solve this problem?
> >
> > You generally have two options on doing multilib builds: either using
> > out-of-source builds or in-source builds. If you decide on the latter,
> > you unnecessarily waste users' time and disk space to create two more
> > copies of sources. I don't think we should go this way.
> >
> > If you decide on out-of-source builds, you basically need proper
> > src_{configure,compile,test,install} and that's what autotools-utils
> > does. Plus:
>  >
>  > - patch applying and autoreconf in src_prepare() -- which are
>  >    completely optional, you are free to write your own src_prepare().
>  >    If you wanted to apply patches by hand, you'd need to write
>  >    src_prepare() anyway.
> 
> It's that "Plus" part that is my problem with autotools-multilib.eclass 
> currently, it adds EXPORT_FUNCTIONS of src_prepare() from 
> autotools-utils.eclass which is irrelevant to the autotools-multilib.eclass
> adds just another eclass/phase function to worry about for inherit order

I understand your concern but I see no way around it. The alternative
solution exports src_prepare() as well to copy the sources -- so it's
even more to worry about than the no-op-by-default.

> > - prune_libtool_files in src_install() which most people want to do
> >    anyway, so that doesn't hurt -- and the pkg-config dep is going to
> >    be removed, by the patch I sent already.
> 
> but lacks a way to pass arguments to prune_libtool_files, like --all, 
> since prune_libtool_files isn't that smart it gets it right everytime
> i propably prefer to stick to manually calling it with or without --all
> and well, this is not related to the multilib conversion so it shouldn't 
> be executed anyway

I can add the ability to pass arguments. So far, hasn't considered it
necessary since the single run doesn't really hurt anything noticeably.

> > - adding libtool args for shared/static libs if IUSE=static-libs --
> >    which I wanted to remove but people considered it useful.
> 
> if it's not related to the multilib conversion, it shouldn't be executed...

It's not about multilib conversion solely.

Multilib conversion requires out-of-source build support. Out-of-source
build support is established using autotools-utils. The logical
conversion order is to:

1) convert the ebuild to autotools-utils, make sure that out-of-source
builds work,

2) convert the ebuild to autotools-multilib.

Some of my conversions actually follow that split, providing two
patches instead of one.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

On 02/24/2013 07:56 PM, Michał Górny wrote:
>> It's that "Plus" part that is my problem with
>> autotools-multilib.eclass currently, it adds EXPORT_FUNCTIONS of
>> src_prepare() from autotools-utils.eclass which is irrelevant to
>> the autotools-multilib.eclass adds just another eclass/phase
>> function to worry about for inherit order
> 
> I understand your concern but I see no way around it. The
> alternative solution exports src_prepare() as well to copy the
> sources -- so it's even more to worry about than the
> no-op-by-default.

No, I don't export src_prepare. The developer has to call
"prepabisources" at the end of src_prepare himself, but only if he
wants to use IN_SOURCE_BUILD (this seems to be a requirement for
waf-utils ebuilds at first glance).

It's a bit similar to prepgamesdirs. I find it easier to require
calling it explicitly since src_prepare is often times a very custom
function.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKmyaAAoJEFpvPKfnPDWzQNsH/iMfm5+k2CuFwX1MEIf28DAp
4onvA2zEKCZCDMU4+eTLr3he04Qhy1NJb2WIqK4ZsRMHZvrtLoDR1PlLSgBN1Zs7
pYOTtOama9M6ha50jZmDptsG6GlZEWkuDvhYloHa1nKmCUaQdUJ6Cks53vkT1WmX
+Xaz/NJUCKARWj4yU6UzYxyh+kklLm/rSZPSDlpu329XD9aPUlRfH+QBQMY5S6gy
88VfbG0al+k0S7aB6Xj8gjCktj3ZLY0b4vMx6d0mrVw6sY1lJnz73Bd4NVCpW2QH
UlLDMthlVLOhRDIxaLcJcSOkEJ4/LDANSR45zQviurqUKjQy68Ve3DztlFaVEXo=
=lp6W
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Samuli Suominen]

On 24/02/13 02:34, hasufell wrote:
> Some people seem to feel uncomfortable with autotools-multilib, because
> it depends on autotools-utils.
>
> Instead of arguing whether it makes sense or not I'd propose a similar
> autotools related eclass.
>
> I also attach an example conversion of media-libs/libexif (the
> maintainer wants to keep the changes minimal).
> Effectively I am only (almost) changing the function names and not the
> ebuild code.

looks good, seems exactly what I wanted

> Feel free to propose a different eclass name.

whatever it will be, please make it shorter, like 'multiabi' maybe

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Samuli Suominen]

On 24/02/13 16:17, hasufell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
>> On 24/02/2013 11:06, Michał Górny wrote:
>>> Then don't put 'autotools' in the name.
>>
>> +1
>>
>
> That would be multilib-minimal.eclass then?

Sounds good to me.

> ABCD also suggested something else:
> autotools-multilib.eclass -> autotools-utils-multilib.eclass

This makes sense too, autotools-multilib.eclass is misleading as it 
embeds the "unrelated" autotools-utils.eclass

So it seems currently that some are against this eclass, some are 
against the whole idea and favour multilib-portage, some are against 
using autotools-utils.eclass for this, ...
Some people are already committing the eclass version changes/fixes to 
tree, some are filing bug reports about bugs caused by it, ...

It would be nice if people agreed but I guess that is not happening, so 
i'll be pushing this eclass to tree under name 'multilib-minimal.eclass' 
if I don't hear compelling arguments for not doing so, or in case you 
push it before me

- Samuli

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Michał Górny]

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

On Wed, 27 Feb 2013 15:01:51 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 24/02/13 16:17, hasufell wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
> >> On 24/02/2013 11:06, Michał Górny wrote:
> >>> Then don't put 'autotools' in the name.
> >>
> >> +1
> >>
> >
> > That would be multilib-minimal.eclass then?
> 
> Sounds good to me.
> 
> > ABCD also suggested something else:
> > autotools-multilib.eclass -> autotools-utils-multilib.eclass
> 
> This makes sense too, autotools-multilib.eclass is misleading as it 
> embeds the "unrelated" autotools-utils.eclass
> 
> So it seems currently that some are against this eclass, some are 
> against the whole idea and favour multilib-portage, some are against 
> using autotools-utils.eclass for this, ...
> Some people are already committing the eclass version changes/fixes to 
> tree, some are filing bug reports about bugs caused by it, ...
> 
> It would be nice if people agreed but I guess that is not happening, so 
> i'll be pushing this eclass to tree under name 'multilib-minimal.eclass' 
> if I don't hear compelling arguments for not doing so, or in case you 
> push it before me

No, don't do it. Or at least wait till I clean up multilib-build a bit.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Pacho Ramos]

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

El mié, 27-02-2013 a las 15:01 +0200, Samuli Suominen escribió:
> On 24/02/13 16:17, hasufell wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
> >> On 24/02/2013 11:06, Michał Górny wrote:
> >>> Then don't put 'autotools' in the name.
> >>
> >> +1
> >>
> >
> > That would be multilib-minimal.eclass then?
> 
> Sounds good to me.
> 
> > ABCD also suggested something else:
> > autotools-multilib.eclass -> autotools-utils-multilib.eclass
> 
> This makes sense too, autotools-multilib.eclass is misleading as it 
> embeds the "unrelated" autotools-utils.eclass
> 
> So it seems currently that some are against this eclass, some are 
> against the whole idea and favour multilib-portage, some are against 
> using autotools-utils.eclass for this, ...
> Some people are already committing the eclass version changes/fixes to 
> tree, some are filing bug reports about bugs caused by it, ...
> 
> It would be nice if people agreed but I guess that is not happening, so 
> i'll be pushing this eclass to tree under name 'multilib-minimal.eclass' 
> if I don't hear compelling arguments for not doing so, or in case you 
> push it before me
> 
> - Samuli
> 
> 

Probably the way to reach higher consensus would be to have an eclass
for supporting out of sources building and make other eclasses rely on
that code, that way people can use autotools-utils or use new eclass
"manually" as they prefer :/

Anyway I don't think autotools-utils includes so much changes :|

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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

On 02/24/2013 11:39 PM, Samuli Suominen wrote:
> On 24/02/13 02:34, hasufell wrote:
>> Some people seem to feel uncomfortable with autotools-multilib, because
>> it depends on autotools-utils.
>>
>> Instead of arguing whether it makes sense or not I'd propose a similar
>> autotools related eclass.
>>
>> I also attach an example conversion of media-libs/libexif (the
>> maintainer wants to keep the changes minimal).
>> Effectively I am only (almost) changing the function names and not the
>> ebuild code.
> 
> looks good, seems exactly what I wanted
> 
>> Feel free to propose a different eclass name.
> 
> whatever it will be, please make it shorter, like 'multiabi' maybe
> 

I cleaned up some things.

1) eclass renamed to multilib-minimal.eclass
prepabisources() renamed to multilib_copy_sources()

2) if someone wants out-of-source builds he gotta handle that manually,
as in: not calling multilib_copy_sources and making sure that stuff like
ECONF_SOURCE is set correctly
(${BUILD_DIR} will be created unconditionally in src_configure anyway)

3) all autotools related code removed

4) Introduced a DISABLE_MULTILIB variable for use of portage-multilib,
which will disable all multilib related stuff. I am not sure if that's
what they want, but I heard something like that.
Tommy should comment on this.

In case this eclass will be deprecated at some point, conversion back to
normal will be trivial anyway.

[-- Attachment #2: multilib-minimal.eclass --]
[-- Type: text/plain, Size: 3408 bytes --]

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

# @ECLASS: multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald <hasufell@gentoo.org>
# @BLURB: wrapper for multilib builds providing convenient multilib_src_* functions
# @DESCRIPTION:
#
# src_configure, src_compile, src_test and src_install are exported
# use multilib_src_* instead of src_* which runs this phase for
# all enabled ABIs
# multilib-minimal should _always_ go last in inherit order!!
#
# If you are using in-source builds, then you must run multilib_copy_sources
# at the end of src_prepare!!
#
# If you need generic install rules, use multilib_src_install_all function.

# @ECLASS-VARIABLE: DISABLE_MULTILIB
# @DESCRIPTION:
# set to ON to disable multilib entirely
# this is not meant to be set in the ebuild
: ${DISABLE_MULTILIB:=OFF}


# EAPI=5 is required for meaningful MULTILIB_USEDEP.
case ${EAPI:-0} in
	5) ;;
	*) die "EAPI=${EAPI} is not supported" ;;
esac

_multilib_inherit=
if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
	_multilib_inherit="multilib-build"
fi

inherit ${_multilib_inherit}

EXPORT_FUNCTIONS src_configure src_compile src_test src_install

multilib_copy_sources() {
	_abi_copy_sources() {
		einfo "${ABI}: copying to ${BUILD_DIR}"
		cp -pR "${S}" "${BUILD_DIR}" || die "failed to copy sources"
	}

	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
		einfo "Will copy sources to abi-specific dirs"
		multilib_foreach_abi _abi_copy_sources
	fi
}

multilib-minimal_src_configure() {
	_common_src_configure() {
		if declare -f multilib_src_configure >/dev/null ; then
			multilib_src_configure
		else
			default_src_configure
		fi
	}

	_abi_src_configure() {
		einfo "${ABI}: Configuring"

		mkdir -p "${BUILD_DIR}" || die
		pushd "${BUILD_DIR}" >/dev/null || die
		_common_src_configure
		popd >/dev/null || die
	}

	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
		multilib_foreach_abi _abi_src_configure
	else
		_common_src_configure
	fi	
}

multilib-minimal_src_compile() {
	_common_src_compile() {
		if declare -f multilib_src_compile >/dev/null ; then
			multilib_src_compile
		else
			default_src_compile
		fi
	}

	_abi_src_compile() {
		einfo "${ABI}: Compiling"

		pushd "${BUILD_DIR}" >/dev/null || die
		_common_src_compile
		popd >/dev/null || die
	}

	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
		multilib_foreach_abi _abi_src_compile
	else
		_common_src_compile
	fi
}

multilib-minimal_src_test() {
	_common_src_test() {
		if declare -f multilib_src_test >/dev/null ; then
			multilib_src_test
		else
			default_src_test
		fi
	}

	_abi_src_test() {
		einfo "${ABI}: Testing"

		pushd "${BUILD_DIR}" >/dev/null || die
		_common_src_test
		popd >/dev/null || die
	}

	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
		multilib_foreach_abi _abi_src_test
	else
		_common_src_test
	fi
}

multilib-minimal_src_install() {
	_common_src_install() {
		if declare -f multilib_src_install >/dev/null ; then
			multilib_src_install
		else
			default_src_install	
		fi
	}

	_abi_src_install() {
		einfo "${ABI}: Installing"

		pushd "${BUILD_DIR}" >/dev/null || die
		_common_src_install
		multilib_check_headers
		popd >/dev/null || die
	}

	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
		multilib_foreach_abi _abi_src_install
	else
		_common_src_install
	fi

	if declare -f multilib_src_install_all >/dev/null ; then
		multilib_src_install_all
	fi
}

[-- Attachment #3: libexif-0.6.21.ebuild.diff --]
[-- Type: text/plain, Size: 1559 bytes --]

--- media-libs/libexif/libexif-0.6.21.ebuild
+++ media-libs/libexif/libexif-0.6.21-r1.ebuild
@@ -2,8 +2,8 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/media-libs/libexif/libexif-0.6.21.ebuild,v 1.8 2012/11/07 19:03:58 grobian Exp $
 
-EAPI=4
-inherit eutils libtool
+EAPI=5
+inherit eutils libtool multilib-minimal
 
 DESCRIPTION="Library for parsing, editing, and saving EXIF data"
 HOMEPAGE="http://libexif.sourceforge.net/"
@@ -11,7 +11,7 @@
 
 LICENSE="LGPL-2.1"
 SLOT="0"
-KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~x64-solaris ~x86-solaris"
+KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~x64-solaris ~x86-solaris"
 IUSE="doc nls static-libs"
 
 RDEPEND="nls? ( virtual/libintl )"
@@ -24,9 +24,10 @@
 	epatch "${FILESDIR}"/${PN}-0.6.13-pkgconfig.patch
 	sed -i -e '/FLAGS=/s:-g::' configure || die #390249
 	elibtoolize # For *-bsd
+	multilib_copy_sources
 }
 
-src_configure() {
+multilib_src_configure() {
 	econf \
 		$(use_enable static-libs static) \
 		$(use_enable nls) \
@@ -34,8 +35,11 @@
 		--with-doc-dir="${EPREFIX}"/usr/share/doc/${PF}
 }
 
-src_install() {
+multilib_src_install() {
 	emake DESTDIR="${D}" install
+}
+
+multilib_src_install_all() {
 	prune_libtool_files
 	rm -f "${ED}"/usr/share/doc/${PF}/{ABOUT-NLS,COPYING}
 }

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Michał Górny]

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

On Thu, 28 Feb 2013 02:06:25 +0100
hasufell <hasufell@gentoo.org> wrote:

> On 02/24/2013 11:39 PM, Samuli Suominen wrote:
> > On 24/02/13 02:34, hasufell wrote:
> >> Some people seem to feel uncomfortable with autotools-multilib, because
> >> it depends on autotools-utils.
> >>
> >> Instead of arguing whether it makes sense or not I'd propose a similar
> >> autotools related eclass.
> >>
> >> I also attach an example conversion of media-libs/libexif (the
> >> maintainer wants to keep the changes minimal).
> >> Effectively I am only (almost) changing the function names and not the
> >> ebuild code.
> > 
> > looks good, seems exactly what I wanted
> > 
> >> Feel free to propose a different eclass name.
> > 
> > whatever it will be, please make it shorter, like 'multiabi' maybe
> > 
> 
> I cleaned up some things.
> 
> 1) eclass renamed to multilib-minimal.eclass

You didn't like multilib-wrapper?

> 4) Introduced a DISABLE_MULTILIB variable for use of portage-multilib,
> which will disable all multilib related stuff. I am not sure if that's
> what they want, but I heard something like that.
> Tommy should comment on this.

Setting that variable would invalidate metadata cache.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

On 02/28/2013 09:30 AM, Michał Górny wrote:
> 
>> 4) Introduced a DISABLE_MULTILIB variable for use of
>> portage-multilib, which will disable all multilib related stuff.
>> I am not sure if that's what they want, but I heard something
>> like that. Tommy should comment on this.
> 
> Setting that variable would invalidate metadata cache.
> 

Yeah, but only for multilib-portage.

Any other solution?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRL3TpAAoJEFpvPKfnPDWzDMgIAI6UXGFBQAnmyvIGTeN16RL4
AOPuycq2uFgGJIE+3dfjVXhcDEyDnUl1lxcL4rINsgVn7Xqxj86A/eqdJ2MLd9xI
/X6esJcHRgad6tClosr7vFfHs/BuFNvWjNKxOlRgf8TNXG64o5JKpTWict7b7OSY
eKLZwuqy0OTVVBCEjLGczMVgTs6ia0ML+Sk1S+UnnKVTfbnqSa5L0cKnLqlbunsq
lcVJOEN42JmOPIR7ImI6D8grQHkMf30pZBHWGsE4KjX3XJvMd0PZKSNlwkgaSkJa
+IcP8hEnyF27QWO60pt+pPQIcJjiCOKC+JUGBQZsjhaOQL7d1a8srNMJNnuYqzo=
=6M4z
-----END PGP SIGNATURE-----

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

On 02/28/2013 09:30 AM, Michał Górny wrote:
> 
> Setting that variable would invalidate metadata cache.
> 

different approach attached

[-- Attachment #2: multilib-build.eclass.patch --]
[-- Type: text/x-patch, Size: 2104 bytes --]

--- eclass/multilib-minimal.eclass
+++ eclass/multilib-minimal.eclass
@@ -18,12 +18,6 @@
 #
 # If you need generic install rules, use multilib_src_install_all function.
 
-# @ECLASS-VARIABLE: DISABLE_MULTILIB
-# @DESCRIPTION:
-# set to ON to disable multilib entirely
-# this is not meant to be set in the ebuild
-: ${DISABLE_MULTILIB:=OFF}
-
 
 # EAPI=5 is required for meaningful MULTILIB_USEDEP.
 case ${EAPI:-0} in
@@ -31,22 +25,28 @@
 	*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
-_multilib_inherit=
-if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
-	_multilib_inherit="multilib-build"
-fi
 
-inherit ${_multilib_inherit}
+inherit multilib-build
 
 EXPORT_FUNCTIONS src_configure src_compile src_test src_install
 
+
+unset DISABLE_MULTILIB
+_multilib-minimal_set_globals() {
+	if [[ $(multilib_get_enabled_abis) == ${DEFAULT_ABI} ]] ; then
+		DISABLE_MULTILIB="ON"
+	fi
+}
+_multilib-minimal_set_globals
+
+
 multilib_copy_sources() {
 	_abi_copy_sources() {
 		einfo "${ABI}: copying to ${BUILD_DIR}"
 		cp -pR "${S}" "${BUILD_DIR}" || die "failed to copy sources"
 	}
 
-	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
+	if [[ -z ${DISABLE_MULTILIB} ]] ; then
 		einfo "Will copy sources to abi-specific dirs"
 		multilib_foreach_abi _abi_copy_sources
 	fi
@@ -70,7 +70,7 @@
 		popd >/dev/null || die
 	}
 
-	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
+	if [[ -z ${DISABLE_MULTILIB} ]] ; then
 		multilib_foreach_abi _abi_src_configure
 	else
 		_common_src_configure
@@ -94,7 +94,7 @@
 		popd >/dev/null || die
 	}
 
-	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
+	if [[ -z ${DISABLE_MULTILIB} ]] ; then
 		multilib_foreach_abi _abi_src_compile
 	else
 		_common_src_compile
@@ -118,7 +118,7 @@
 		popd >/dev/null || die
 	}
 
-	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
+	if [[ -z ${DISABLE_MULTILIB} ]] ; then
 		multilib_foreach_abi _abi_src_test
 	else
 		_common_src_test
@@ -143,7 +143,7 @@
 		popd >/dev/null || die
 	}
 
-	if [[ ${DISABLE_MULTILIB} == "OFF" ]] ; then
+	if [[ -z ${DISABLE_MULTILIB} ]] ; then
 		multilib_foreach_abi _abi_src_install
 	else
 		_common_src_install

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Michał Górny]

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

On Sat, 02 Mar 2013 03:50:11 +0100
hasufell <hasufell@gentoo.org> wrote:

> On 02/28/2013 09:30 AM, Michał Górny wrote:
> > 
> > Setting that variable would invalidate metadata cache.
> > 
> 
> different approach attached

I'm afraid you are doing too much, too fast and I simply can't follow.

I don't think you should introduce workarounds in your eclass. I think
multilib-build should be the place to do that.

And please don't attach patches to patched version since that's too
hard to follow.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[hasufell]

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

On 03/02/2013 04:07 PM, Michał Górny wrote:
> I don't think you should introduce workarounds in your eclass. I think
> multilib-build should be the place to do that.

Feel free to implement a solution. I think an explicit variable might
even be better instead of some magical checks which could cause
unexpected behavior for in-source builds or ebuilds that do a lot of
additional stuff on top of these eclasses.
So in case that solution breaks something, it would only be for
multilib-portage and they could still handle that via masking those
packages.

> 
> And please don't attach patches to patched version since that's too
> hard to follow.
> 

I didn't. However, here is the full version.

[-- Attachment #2: multilib-minimal.eclass --]
[-- Type: text/plain, Size: 3287 bytes --]

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

# @ECLASS: multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald <hasufell@gentoo.org>
# @BLURB: wrapper for multilib builds providing convenient multilib_src_* functions
# @DESCRIPTION:
#
# src_configure, src_compile, src_test and src_install are exported
# use multilib_src_* instead of src_* which runs this phase for
# all enabled ABIs
# multilib-minimal should _always_ go last in inherit order!!
#
# If you are using in-source builds, then you must run multilib_copy_sources
# at the end of src_prepare!!
#
# If you need generic install rules, use multilib_src_install_all function.


# EAPI=5 is required for meaningful MULTILIB_USEDEP.
case ${EAPI:-0} in
	5) ;;
	*) die "EAPI=${EAPI} is not supported" ;;
esac


inherit multilib-build

EXPORT_FUNCTIONS src_configure src_compile src_test src_install


unset DISABLE_MULTILIB
_multilib-minimal_set_globals() {
	if [[ $(multilib_get_enabled_abis) == ${DEFAULT_ABI} ]] ; then
		DISABLE_MULTILIB="ON"
	fi
}
_multilib-minimal_set_globals


multilib_copy_sources() {
	_abi_copy_sources() {
		einfo "${ABI}: copying to ${BUILD_DIR}"
		cp -pR "${S}" "${BUILD_DIR}" || die "failed to copy sources"
	}

	if [[ -z ${DISABLE_MULTILIB} ]] ; then
		einfo "Will copy sources to abi-specific dirs"
		multilib_foreach_abi _abi_copy_sources
	fi
}

multilib-minimal_src_configure() {
	_common_src_configure() {
		if declare -f multilib_src_configure >/dev/null ; then
			multilib_src_configure
		else
			default_src_configure
		fi
	}

	_abi_src_configure() {
		einfo "${ABI}: Configuring"

		mkdir -p "${BUILD_DIR}" || die
		pushd "${BUILD_DIR}" >/dev/null || die
		_common_src_configure
		popd >/dev/null || die
	}

	if [[ -z ${DISABLE_MULTILIB} ]] ; then
		multilib_foreach_abi _abi_src_configure
	else
		_common_src_configure
	fi	
}

multilib-minimal_src_compile() {
	_common_src_compile() {
		if declare -f multilib_src_compile >/dev/null ; then
			multilib_src_compile
		else
			default_src_compile
		fi
	}

	_abi_src_compile() {
		einfo "${ABI}: Compiling"

		pushd "${BUILD_DIR}" >/dev/null || die
		_common_src_compile
		popd >/dev/null || die
	}

	if [[ -z ${DISABLE_MULTILIB} ]] ; then
		multilib_foreach_abi _abi_src_compile
	else
		_common_src_compile
	fi
}

multilib-minimal_src_test() {
	_common_src_test() {
		if declare -f multilib_src_test >/dev/null ; then
			multilib_src_test
		else
			default_src_test
		fi
	}

	_abi_src_test() {
		einfo "${ABI}: Testing"

		pushd "${BUILD_DIR}" >/dev/null || die
		_common_src_test
		popd >/dev/null || die
	}

	if [[ -z ${DISABLE_MULTILIB} ]] ; then
		multilib_foreach_abi _abi_src_test
	else
		_common_src_test
	fi
}

multilib-minimal_src_install() {
	_common_src_install() {
		if declare -f multilib_src_install >/dev/null ; then
			multilib_src_install
		else
			default_src_install	
		fi
	}

	_abi_src_install() {
		einfo "${ABI}: Installing"

		pushd "${BUILD_DIR}" >/dev/null || die
		_common_src_install
		multilib_check_headers
		popd >/dev/null || die
	}

	if [[ -z ${DISABLE_MULTILIB} ]] ; then
		multilib_foreach_abi _abi_src_install
	else
		_common_src_install
	fi

	if declare -f multilib_src_install_all >/dev/null ; then
		multilib_src_install_all
	fi
}