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

[Michał Górny]

On Sat, 02 Mar 2013 03:50:11 +0100
hasufell hasuf...@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


signature.asc
Description: PGP signature

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

[hasufell]

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.
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald hasuf...@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
}

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

[hasufell]

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

different approach attached
--- 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]

On Thu, 28 Feb 2013 02:06:25 +0100
hasufell hasuf...@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


signature.asc
Description: PGP signature

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

[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]

On Wed, 27 Feb 2013 15:01:51 +0200
Samuli Suominen ssuomi...@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


signature.asc
Description: PGP signature

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

[Pacho Ramos]

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 :|


signature.asc
Description: This is a digitally signed message part

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

[hasufell]

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.
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: multilib-minimal.eclass
# @MAINTAINER:
# Julian Ospald hasuf...@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() 

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

[Michał Górny]

On Sun, 24 Feb 2013 05:22:43 +0100
hasufell hasuf...@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


signature.asc
Description: PGP signature

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

[Diego Elio Pettenò]

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
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



signature.asc
Description: OpenPGP digital signature

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]

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 :/




signature.asc
Description: This is a digitally signed message part

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

[Michał Górny]

On Sun, 24 Feb 2013 05:22:43 +0100
hasufell hasuf...@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


signature.asc
Description: PGP signature

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 hasuf...@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]

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 



signature.asc
Description: This is a digitally signed message part

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

[Michał Górny]

On Sun, 24 Feb 2013 16:12:18 +0100
Pacho Ramos pa...@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


signature.asc
Description: PGP signature

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

[Pacho Ramos]

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 pa...@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



signature.asc
Description: This is a digitally signed message part

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

[Alexis Ballier]

On Sun, 24 Feb 2013 01:34:47 +0100
hasufell hasuf...@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 mgo...@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]

On 02/24/2013 05:22 PM, Alexis Ballier wrote:
 On Sun, 24 Feb 2013 01:34:47 +0100
 hasufell hasuf...@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.
--- 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

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

[Alexis Ballier]

On Sun, 24 Feb 2013 17:42:26 +0100
hasufell hasuf...@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]

On Sun, 24 Feb 2013 18:58:08 +0200
Samuli Suominen ssuomi...@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


signature.asc
Description: PGP signature

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

[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.