Re: [gentoo-dev] New eclass: autotools-multilib-minimal
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
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
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
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
-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
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
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
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
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
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
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
-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
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
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
-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
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
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
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
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
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
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
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
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
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
-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
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
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.