Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Thu, 03 Jan 2013 11:44:58 +0100
Thomas Sachau to...@gentoo.org wrote:
Pacho Ramos schrieb:
El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió:
On Sun, 23 Sep 2012 16:49:13 +0200
Thomas Sachau to...@gentoo.org wrote:
It is not hard by itself to inherit an eclass. There is just the
limitation, that occurs with an eclass, e.g.:
-the one from mgorny only does it for autotools based ebuilds
only and even there only for libraries, headers and binaries are
not done. While one may create the same for cmake based ones,
those are still only for a subset of packages, since not all do
use autotools/cmake or are satisfied with a libs only solution
-the multilib-native eclass does extend it way more, but still
has its limitations, e.g. what happens with a new target ABI
(like x32 on the amd64 profile) or how are dependencies handled?
multilib-portage is the answer to those limitations, since it does
work for any target with multilib cross-compile support, can
handle things like the dependencies internally and can even work
on not prepared/modified ebuilds.
So before i invest even more time in getting this official, we
should better get to some conclusion, if we either go the route
with eclass based multilib cross-compile support with its
limitations or if we move this up to the package manager level.
Can't we get something in between ?
Unless I'm mistaken, portage-multilib has its limitations also:
- I have package foo and package bar, both depending on ffmpeg and
canditates for a multilib build. However, package foo does not
link to ffmpeg but simply spawns the 'ffmpeg' binary to process
some files, package bar links to libavcodec. You need
ffmpeg[multilib] for a multilib build of bar but not for foo. How
do you distinguish between the two ?
I dont really understand your question here. So do you:
- simply have 2 64bit apps wanting to use ffmpeg?
- have 2 32bit binary packages wanting to use ffmpeg?
- want to build foo and bar on a 64bit platform for a 32bit platform?
- want a 64bit or a 32bit version of ffmpeg or both?
- if you want a 32bit version of ffmpeg, do you only want 32bit libs
or also a 32bit binary?
it depends on what you are building; let's say we want all abi flavors
for foo and bar.
in the above example, package foo uses fork/exec so needs a libc
compatible with its abis and that's all; it doesn't care if ffmpeg is
an elf executable, a bash script, or running through an emulator.
package bar needs ffmpeg libraries for every abi it installs.
portage multilib doesn't seem to distinguish between the two cases.
- When an out-of-tree build is possible, it is more efficient to
do it that way while multilib-portage will probably run the full
src_* phases twice. mgorny's eclass is a solution to this for
autotools-utils based ebuilds. I have added basic support for
this in freebsd-lib some time ago also.
Isnt out-of-tree build just building in a seperate location, so in
the end doing one unpack instead of 2, while everything else still
needs to be done for each target?
yes, so?
(unpack in the EAPI0 sense btw, prepare shouldn't need to be done twice
either)
However, it is clear that USE=multilib is limited too. What we
probably need, as I read in the draft you posted some time ago, is
a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in
an eclass, add them to IUSE of multilib-enabled packages and then
you can use the USE-deps. When a new ABI gets added, add it to the
list in the eclass and be done. You already have PM support for
this :)
Please keep in mind, that the USE flags are different, depending on
your arch. E.g. on amd64, you may additionally have x86 and x32,
while on ppc64, you may have ppc64 and ppc. You dont want the later
on amd64 nor the first on ppc. So how do you want to add different
(use-expanded) USE flags based on the arch the user is running?
no, the useflags are not different:
coma=
for i in $MULTILIB_ABIS ; do
multilib_use_deps+=${coma}multilib_abi_${i}?
coma=,
done
deps like foo[multilib?] becomes foo[${multilib_use_deps}]
and voila, you are not anymore limited to multilib or not multilib but
really control the abis.
You can leverage the generic multilib building code you have to an
eclass, so that you don't need to spec it; spec-ing it has its
problems too: what happens if next year pkg-config is deprecated
and now we shall all use foo-config ? your spec adjusts
PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small
EAPI change to be able to implement sanely a generic solution into
an eclass though.
My question to you would be: what are we missing from current
EAPIs to be able to perfectly support multilib builds ?
While the variable export, the build for each target and the merge of
the results should also be possible inside an eclass, the dependency
and USE flag parts seems more
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 14 Jan 2013 15:04:45 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Thu, 03 Jan 2013 11:44:58 +0100
Thomas Sachau to...@gentoo.org wrote:
Please keep in mind, that the USE flags are different, depending on
your arch. E.g. on amd64, you may additionally have x86 and x32,
while on ppc64, you may have ppc64 and ppc. You dont want the later
on amd64 nor the first on ppc. So how do you want to add different
(use-expanded) USE flags based on the arch the user is running?
no, the useflags are not different:
coma=
for i in $MULTILIB_ABIS ; do
multilib_use_deps+=${coma}multilib_abi_${i}?
coma=,
done
deps like foo[multilib?] becomes foo[${multilib_use_deps}]
and voila, you are not anymore limited to multilib or not multilib but
really control the abis.
Hmm, it may be a good idea to introduce such a variable already.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Pacho Ramos schrieb: El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió: On Sun, 23 Sep 2012 16:49:13 +0200 Thomas Sachau to...@gentoo.org wrote: It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. Can't we get something in between ? Unless I'm mistaken, portage-multilib has its limitations also: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a multilib build of bar but not for foo. How do you distinguish between the two ? I dont really understand your question here. So do you: - simply have 2 64bit apps wanting to use ffmpeg? - have 2 32bit binary packages wanting to use ffmpeg? - want to build foo and bar on a 64bit platform for a 32bit platform? - want a 64bit or a 32bit version of ffmpeg or both? - if you want a 32bit version of ffmpeg, do you only want 32bit libs or also a 32bit binary? - When an out-of-tree build is possible, it is more efficient to do it that way while multilib-portage will probably run the full src_* phases twice. mgorny's eclass is a solution to this for autotools-utils based ebuilds. I have added basic support for this in freebsd-lib some time ago also. Isnt out-of-tree build just building in a seperate location, so in the end doing one unpack instead of 2, while everything else still needs to be done for each target? However, it is clear that USE=multilib is limited too. What we probably need, as I read in the draft you posted some time ago, is a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an eclass, add them to IUSE of multilib-enabled packages and then you can use the USE-deps. When a new ABI gets added, add it to the list in the eclass and be done. You already have PM support for this :) Please keep in mind, that the USE flags are different, depending on your arch. E.g. on amd64, you may additionally have x86 and x32, while on ppc64, you may have ppc64 and ppc. You dont want the later on amd64 nor the first on ppc. So how do you want to add different (use-expanded) USE flags based on the arch the user is running? You can leverage the generic multilib building code you have to an eclass, so that you don't need to spec it; spec-ing it has its problems too: what happens if next year pkg-config is deprecated and now we shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small EAPI change to be able to implement sanely a generic solution into an eclass though. My question to you would be: what are we missing from current EAPIs to be able to perfectly support multilib builds ? While the variable export, the build for each target and the merge of the results should also be possible inside an eclass, the dependency and USE flag parts seems more tricky. And additionally, with support of this in (multilib-)portage (not depending on EAPI, but enabled via FEATURES), i already get all of this without having to wait for a new EAPI/eclass and ebuilds moving to it. What finally occurred with this? What would be the problem of opting by this mixed solution (eclass for some packages and PM features requiring newer eapi for others)? I guess nothing new. Nobody yet provided an eclass providing the full support for everything i have in multilib-portage and i did not create the requested PMS-diff yet. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió: On Sun, 23 Sep 2012 16:49:13 +0200 Thomas Sachau to...@gentoo.org wrote: It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. Can't we get something in between ? Unless I'm mistaken, portage-multilib has its limitations also: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a multilib build of bar but not for foo. How do you distinguish between the two ? - When an out-of-tree build is possible, it is more efficient to do it that way while multilib-portage will probably run the full src_* phases twice. mgorny's eclass is a solution to this for autotools-utils based ebuilds. I have added basic support for this in freebsd-lib some time ago also. However, it is clear that USE=multilib is limited too. What we probably need, as I read in the draft you posted some time ago, is a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an eclass, add them to IUSE of multilib-enabled packages and then you can use the USE-deps. When a new ABI gets added, add it to the list in the eclass and be done. You already have PM support for this :) You can leverage the generic multilib building code you have to an eclass, so that you don't need to spec it; spec-ing it has its problems too: what happens if next year pkg-config is deprecated and now we shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small EAPI change to be able to implement sanely a generic solution into an eclass though. My question to you would be: what are we missing from current EAPIs to be able to perfectly support multilib builds ? A. What finally occurred with this? What would be the problem of opting by this mixed solution (eclass for some packages and PM features requiring newer eapi for others)? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Alexis Ballier wrote: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a multilib build of bar but not for foo. How do you distinguish between the two ? foo.ebuild has RDEPEND=ffmpeg bar.ebuild has DEPEND=ffmpeg[multilib?] Right? - When an out-of-tree build is possible, it is more efficient to do it that way while multilib-portage will probably run the full src_* phases twice. Certainly. //Peter
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 17:44:33 -0700
Matt Turner matts...@gentoo.org wrote:
On Mon, Sep 24, 2012 at 3:22 PM, Alexis Ballier aball...@gentoo.org
wrote:
On Tue, 25 Sep 2012 00:10:21 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you:
call directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
How can an eclass call a phase function while eclass needs to be
called from the phase function to call the phase function...?
Read again. Esp. the part you deleted.
I never said it should do this, on purpose...
I'm especially confused by what your point is. I can't see how your
snippet could ever work, and you're being evasive about answering
that.
both of you are putting words in my mouth then: obviously, if you call
your eclass multilib and the above function multilib_src_compile and
then pass it through EXPORT_FUNCTIONS, then it will loop.
let me copy paste what i wrote for you:
then, in a future EAPI, let the PM call src_multilib_compile instead
of src_compile if multilib is requested.
nothing more...
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 16:49:13 +0200 Thomas Sachau to...@gentoo.org wrote: It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. Can't we get something in between ? Unless I'm mistaken, portage-multilib has its limitations also: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a multilib build of bar but not for foo. How do you distinguish between the two ? - When an out-of-tree build is possible, it is more efficient to do it that way while multilib-portage will probably run the full src_* phases twice. mgorny's eclass is a solution to this for autotools-utils based ebuilds. I have added basic support for this in freebsd-lib some time ago also. However, it is clear that USE=multilib is limited too. What we probably need, as I read in the draft you posted some time ago, is a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an eclass, add them to IUSE of multilib-enabled packages and then you can use the USE-deps. When a new ABI gets added, add it to the list in the eclass and be done. You already have PM support for this :) You can leverage the generic multilib building code you have to an eclass, so that you don't need to spec it; spec-ing it has its problems too: what happens if next year pkg-config is deprecated and now we shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small EAPI change to be able to implement sanely a generic solution into an eclass though. My question to you would be: what are we missing from current EAPIs to be able to perfectly support multilib builds ? A.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 18:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. cp -l ? I can live with that.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 12:17:58 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 18:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. cp -l ? I can live with that. Can you guarantee that the build system won't modify any file in the source tree? And AFAIR we don't have any COW filesystems in Gentoo. So it's back to optimized solution vs bad, universal solution. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 19:32:14 +0200 Michał Górny mgo...@gentoo.org wrote: On Mon, 24 Sep 2012 12:17:58 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 18:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. cp -l ? I can live with that. Can you guarantee that the build system won't modify any file in the source tree? You can add it as a requirement. Your eclass implicitly requires it anyway. So it's back to optimized solution vs bad, universal solution. or rather writing multilib support for every package vs. using what ebuilds already offer you: a common API for building every package.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 14:53:27 -0300 Alexis Ballier aball...@gentoo.org wrote: On Mon, 24 Sep 2012 19:32:14 +0200 Michał Górny mgo...@gentoo.org wrote: On Mon, 24 Sep 2012 12:17:58 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 18:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. cp -l ? I can live with that. Can you guarantee that the build system won't modify any file in the source tree? You can add it as a requirement. Your eclass implicitly requires it anyway. So it's back to optimized solution vs bad, universal solution. or rather writing multilib support for every package vs. using what ebuilds already offer you: a common API for building every package. Ebuilds don't offer me anything if I have to rewrite phase functions anyway... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 20:12:40 +0200 Michał Górny mgo...@gentoo.org wrote: to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? [...] Ebuilds don't offer me anything if I have to rewrite phase functions anyway... what, in the above quote, makes you think you need to rewrite anything ?
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 16:16:53 -0300 Alexis Ballier aball...@gentoo.org wrote: On Mon, 24 Sep 2012 20:12:40 +0200 Michał Górny mgo...@gentoo.org wrote: to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? [...] Ebuilds don't offer me anything if I have to rewrite phase functions anyway... what, in the above quote, makes you think you need to rewrite anything ? 1. If ebuild has phase functions, they override the eclass. 2. If eclass exports phase functions, they have no way of calling 'previous' eclass phase functions. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 22:47:33 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 16:16:53 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 20:12:40 +0200
Michał Górny mgo...@gentoo.org wrote:
to some extent, can't you do the same by unpacking
twice to different $S and calling
src_prepare/compile/install instead of their
autotools-utils counterpart with tweaked $S so that
it works with almost every ebuild ?
[...]
Ebuilds don't offer me anything if I have to rewrite phase
functions anyway...
what, in the above quote, makes you think you need to rewrite
anything ?
1. If ebuild has phase functions, they override the eclass.
2. If eclass exports phase functions, they have no way of calling
'previous' eclass phase functions.
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
then, in a future EAPI, let the PM call src_multilib_compile instead
of src_compile if multilib is requested.
this needs very minimal PM/EAPI support, leaves the multilib code
into eclasses, leaves multilib opt-in so that noarch or packages not
installing a lib dont need to care, and also leaves room for cleaner
more specific eclasses like yours
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
How can an eclass call a phase function while eclass needs to be called
from the phase function to call the phase function...?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Tue, 25 Sep 2012 00:10:21 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you:
call directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
How can an eclass call a phase function while eclass needs to be
called from the phase function to call the phase function...?
Read again. Esp. the part you deleted.
I never said it should do this, on purpose...
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, Sep 24, 2012 at 3:22 PM, Alexis Ballier aball...@gentoo.org wrote:
On Tue, 25 Sep 2012 00:10:21 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you:
call directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
How can an eclass call a phase function while eclass needs to be
called from the phase function to call the phase function...?
Read again. Esp. the part you deleted.
I never said it should do this, on purpose...
I'm especially confused by what your point is. I can't see how your
snippet could ever work, and you're being evasive about answering
that.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. The good solutions should not be made ugly to support corner cases. -- this really starts to resemble multilib portage :) I've said already that multilib is a thing which could be done by eclasses and doesn't need making PM scary. And Tommy says that multilib-portage handles packages having IUSE=multilib fine. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. - -1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQXt4ZAAoJEFpvPKfnPDWzuaUH/0EfL7BxiHQo+E1KvUHNrqlX YD1bt5c/TU82XMAQ4axqYDXSYHE8o/WYJPNFJy2ZZhseFlG1lOo9DxOd+zVIf7JE JqbIWbgJ6r+POKWREDTH8ZWQaq3r1G4BeOH7IbxwuGrLmTUp36oSpVRYX5XnXyl0 3MvRe9bXpih8exwOJudncc/4NFtX9c12wO6CifH0xKwcr7lu7k6jpRyfD3dIpXXq QQlY4MjuCfy6aHxp+4+CvL9WEZ4cmkXxoi/EZCsMZYb+jBQ1NF0Jxr6tULX575vz Vvm+n3sdTPMkh863vrAmglwFYtDgucmp/OeYZD03g3Ef52x1/NefkIGcwXGUjlY= =FXgk -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 12:02:01 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. How is it stronger? By doing implicit magic on every ebuild? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. Looks interesting, yes, it uses cmake. I guess we would need to move all packages needing 32bits libs to this eclasses. Are you sure wouldn't be better to try to go to an upper level like Alexis Ballier suggested some messages ago?: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? -- this really starts to resemble multilib portage :) That would be better as there are a ton of ebuilds not inheritting autotools-utils.eclass even being autotools based (think for example in gnome packages or many others) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 13:03:56 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. Looks interesting, yes, it uses cmake. I guess we would need to move all packages needing 32bits libs to this eclasses. Are you sure wouldn't be better to try to go to an upper level like Alexis Ballier suggested some messages ago?: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? -- this really starts to resemble multilib portage :) That would be better as there are a ton of ebuilds not inheritting autotools-utils.eclass even being autotools based (think for example in gnome packages or many others) You could fix those ebuilds to inherit it too ;). autotools-utils was especially designed to use out-of-source builds for multilib in the future. I'm afraid the 'upper level' is technically impossible without either going into PM itself (which means waiting for EAPI 6 at least and getting some scary logic into it) or reinventing the phases alike ruby-ng/python-distutils-ng. Well, the latter may be useful to some degree; still, it would require each ebuild to redefine all phases. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 13:03:56 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. Looks interesting, yes, it uses cmake. I guess we would need to move all packages needing 32bits libs to this eclasses. Are you sure wouldn't be better to try to go to an upper level like Alexis Ballier suggested some messages ago?: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? -- this really starts to resemble multilib portage :) That would be better as there are a ton of ebuilds not inheritting autotools-utils.eclass even being autotools based (think for example in gnome packages or many others) You could fix those ebuilds to inherit it too ;). autotools-utils was especially designed to use out-of-source builds for multilib in the future. I'm afraid the 'upper level' is technically impossible without either going into PM itself (which means waiting for EAPI 6 at least and getting some scary logic into it) or reinventing the phases alike ruby-ng/python-distutils-ng. Well, the latter may be useful to some degree; still, it would require each ebuild to redefine all phases. Then, I think that main blocker to use autotools-utils.eclass more widely is that it needs at least eapi2, then, I am unsure if all packages currently shipped in emul packages could bump their eapi due compat with old systems. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Pacho Ramos schrieb: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages you mean something like this one? https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass That was the original eclass allowing cross-compile support, but required ebuilds to inherit it. multilib-portage is based on this, but does not require to modify the ebuilds themselves. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 13:30:41 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 13:03:56 +0200 Pacho Ramos pa...@gentoo.org wrote: That would be better as there are a ton of ebuilds not inheritting autotools-utils.eclass even being autotools based (think for example in gnome packages or many others) You could fix those ebuilds to inherit it too ;). autotools-utils was especially designed to use out-of-source builds for multilib in the future. I'm afraid the 'upper level' is technically impossible without either going into PM itself (which means waiting for EAPI 6 at least and getting some scary logic into it) or reinventing the phases alike ruby-ng/python-distutils-ng. Well, the latter may be useful to some degree; still, it would require each ebuild to redefine all phases. Then, I think that main blocker to use autotools-utils.eclass more widely is that it needs at least eapi2, then, I am unsure if all packages currently shipped in emul packages could bump their eapi due compat with old systems. I doubt that is an important problem anymore, considering that portage requires at least EAPI 2 (and some ebuilds use EAPI 3 already). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 12:40 PM, Michał Górny wrote: On Sun, 23 Sep 2012 12:02:01 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. How is it stronger? By doing implicit magic on every ebuild? a) does not involve modifying ebuilds b) works in a larger scale c) is tested and developed for quite some time -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQXvsmAAoJEFpvPKfnPDWzZAcH/11b4Wng7f+nyDpbFQhanpLW 56mQy4IGmEvmEqgrYyBPLtnXWh+BtNu+j0ogS8hNMxsVXvDw6HvJGbeXwebcQ6VY OQS5l0IZvK9Zz+H4wm+ACv1i6fWPG9nRuMg8phRwfnq0jMIIF2lP1nll5T/2QYU/ fvPxiweKca9id4hozc0C0319vpVjEoX9a8/dBh6JXGNlzPq54bf7+6qep8O7mWGo 9bKXkoobwd22wUnBajcOFg4mbMu7cnKsTn0PhQBXo2+tEV5MhgugGe8USq99u8xA CQVVRcdbjyQZW90W8c0/Dniq8LMcTY6xoKmH5a2vG0dpHahYtKtCZ2sTruxgppc= =KNcl -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió: Pacho Ramos schrieb: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages you mean something like this one? https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass That was the original eclass allowing cross-compile support, but required ebuilds to inherit it. multilib-portage is based on this, but does not require to modify the ebuilds themselves. Yes, that is what I meant... but I don't find hard to modify ebuilds to inherit it :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 14:05:58 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 12:40 PM, Michał Górny wrote: On Sun, 23 Sep 2012 12:02:01 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. How is it stronger? By doing implicit magic on every ebuild? a) does not involve modifying ebuilds How can you tell whether a particular ebuild does install libraries which are suitable for multilib? Or are we enforcing multilib for every single program now? c) is tested and developed for quite some time Building packages on two ABIs was developed quite a long time ago, and was tested since. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El sáb, 22-09-2012 a las 23:24 +0200, Michał Górny escribió: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Use case: xorg packages, ask Matt. --- gx86/eclass/autotools-multilib.eclass | 72 +++ 1 file changed, 72 insertions(+) create mode 100644 gx86/eclass/autotools-multilib.eclass diff --git a/gx86/eclass/autotools-multilib.eclass b/gx86/eclass/autotools-multilib.eclass new file mode 100644 index 000..1a345a1 --- /dev/null +++ b/gx86/eclass/autotools-multilib.eclass @@ -0,0 +1,72 @@ +# Copyright 1999-2012 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 +# $Header: $ + +# @ECLASS: autotools-multilib.eclass +# @MAINTAINER: +# Michał Górny mgo...@gentoo.org +# @BLURB: autotools-utils wrapper for multilib builds +# @DESCRIPTION: +# The autotools-multilib.eclass is an autotools-utils.eclass(5) wrapper +# introducing support for building for more than one ABI (multilib). +# +# Inheriting this eclass sets IUSE=multilib and exports autotools-utils +# phase function wrappers which build the package for each supported ABI +# if the flag is enabled. Otherwise, it works like regular +# autotools-utils. [...] One problem that I remembered now: If every ebuild inheritting this eclass (either this one or similar) will add a multilib USE, people running multilib profiles will get it enabled for ALL packages inheritting it, causing them to see how their systems grow a lot because they will have 32bits libs for all packages, even when not needed. For example, in my systems I need gtk+ 32 bits libs, but not qt ones as I don't have any qt based app requiring 32bits installed. Maybe the way to workaround this would be to rename it to something like 32bits, that way if, for example, acroread RDEPENDs on gtk+[32bits], it would only be enabled for needed packages not all signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Michał, Pacho, and everyone else who suck epically at this: CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS! Thank you //Peter pgpJmV3IkjFsp.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Pacho Ramos schrieb: El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió: Pacho Ramos schrieb: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages you mean something like this one? https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass That was the original eclass allowing cross-compile support, but required ebuilds to inherit it. multilib-portage is based on this, but does not require to modify the ebuilds themselves. Yes, that is what I meant... but I don't find hard to modify ebuilds to inherit it :/ It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? The good solutions should not be made ugly to support corner cases. You are tying support to one specific build system, and one specific usage within ebuilds. That is what I would call a corner case :) Ebuilds already define a standardized way of building packages, why not use this directly ? I'm not saying your proposal is useless, it is indeed more efficient than a generic one, but rather that a generic solution is neither much more complicated nor that inefficient in comparison. -- this really starts to resemble multilib portage :) I've said already that multilib is a thing which could be done by eclasses and doesn't need making PM scary. And Tommy says that multilib-portage handles packages having IUSE=multilib fine. I agree with that, it also has two main advantages over multilib portage: it can be used right now and ensures that packages have their multilib builds tested before exposing it to users. A.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On 22/09/2012 20:42, Matt Turner wrote: I think this means make 32-bit binary packages' dependencies on amd64 not use the emul- packages? If so, that'd certainly be a component of getting rid of emul-linux-x86-xlibs. It's not in the scope of my project to get rid of /all/ of the emul- packages, but I agree that that is a worthwhile goal. Mostly I don't want to have to build Xaw in both variants given I use neither.. but that would happen if you just made the emul depend on the packages that are converted... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 23 Sep 2012 09:21:20 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 21:46:02 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? That would make this solution inefficient. Why ? Because it introduces unnecessarily copying files around. The good solutions should not be made ugly to support corner cases. You are tying support to one specific build system, and one specific usage within ebuilds. That is what I would call a corner case :) Ebuilds already define a standardized way of building packages, why not use this directly ? I'm not saying your proposal is useless, it is indeed more efficient than a generic one, but rather that a generic solution is neither much more complicated nor that inefficient in comparison. It's a common case. A generic solution is more complicated if it is supposed to use phase functions exported by some eclass. By using a generic solution you lose the ability to 'automagically' use last exported function. Some time ago I suggested replacing 'default' with something like 'next' (which would allow one exported phase function to call the one from next inherited eclass) but I don't think I got any response. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, 23 Sep 2012 16:26:55 +0200 Peter Stuge pe...@stuge.se wrote: Michał, Pacho, and everyone else who suck epically at this: CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS! I've trimmed them in the next e-mail to the one you replied to :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 9:07 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 22/09/2012 20:42, Matt Turner wrote: I think this means make 32-bit binary packages' dependencies on amd64 not use the emul- packages? If so, that'd certainly be a component of getting rid of emul-linux-x86-xlibs. It's not in the scope of my project to get rid of /all/ of the emul- packages, but I agree that that is a worthwhile goal. Mostly I don't want to have to build Xaw in both variants given I use neither.. but that would happen if you just made the emul depend on the packages that are converted... Ahh, indeed. You mean that existing dependencies on emul-linux-x86-xlibs should be converted into finer-grained dependencies on individual libraries. Of course, that is a very good idea. In the case of Xaw, I added a deprecated USE flag recently that controls the building of the old Xaw6, so we're already working toward trimming Xaw from users' systems. :)
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 3:02 AM, hasufell hasuf...@gentoo.org wrote: I prefer the stronger solution. This is just a quick workaround. And I'd prefer if people who aren't involved with what I'm working on don't try to block my progress. I appreciate your opinion, and truthfully I'd just rather have portage handle this for me but until that time comes I'm going to use Michal's eclass.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 2:07 AM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. I'd much rather have portage handle this for me as well. Unfortunately, the last mail I see about multilib-portage is from two months ago. If it were in EAPI 5, I'd be happy to wait for it. If it even looked like it were progressing, I might wait. But, as you know, gentoo-dev is where ideas go to die. As far as ebuild conversions go, this is really simple. So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. That seems like a reasonable request. Let me re-read the previously mentioned thread and get back to you.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 5:30 AM, Pacho Ramos pa...@gentoo.org wrote: One problem that I remembered now: If every ebuild inheritting this eclass (either this one or similar) will add a multilib USE, people running multilib profiles will get it enabled for ALL packages inheritting it, causing them to see how their systems grow a lot because they will have 32bits libs for all packages, even when not needed. For example, in my systems I need gtk+ 32 bits libs, but not qt ones as I don't have any qt based app requiring 32bits installed. Currently, yes, that is the case. The fix is pretty simple though, and is in progress: https://bugs.gentoo.org/show_bug.cgi?id=435094 (previously mentioned in this thread...)
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On 09/23/2012 03:02 AM, hasufell wrote: On 09/23/2012 11:56 AM, Michał Górny wrote: So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. I prefer the stronger solution. This is just a quick workaround. -1 I'm in favor of adding multilib functions to the package manager in a future EAPI, but I'm not convinced that the current multilib-portage branch is using the best design. For example, it recently came to my attention that it calls pkg_preinst in a loop for each multilib-ABI. This seems like a bad idea to me, since pkg_preinst often contains stuff that only needs to run once, rather than for each multilib-ABI. I would prefer that such loops be coded explicitly in pkg_preinst whenever they are needed, and approach taken by the proposed autotools-multilib.eclass is more in alignment with this preference. -- Thanks, Zac
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On 23 September 2012 18:40, Michał Górny mgo...@gentoo.org wrote: On Sun, 23 Sep 2012 12:33:58 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió: On Sun, 23 Sep 2012 11:07:30 +0200 Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. s/when/if/ So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. I prefer the simpler solution. P.S.: I know, that users, who want up-to-date 32bit drivers for games and wine do use multilib-portage, so we already have a working solution for this issue. They will no longer have to do that. I would prefer if eclass way could be extended to packages not using autotools too, otherwise, we will still need emul packages for, for example, qt libs. If that would be possible via eclass, maybe multilib-portage wouldn't be needed but, if not, we will still need it and, then, would be nice if this inclussion for autotools packages wouldn't cause more problems to get the strong solution land in the near future :/ The simpler solution (eclass) looks fine to me, but it would need to be extended to more packages than autotools based ones to let it replace portage-multilib/emul packages Qt uses cmake, doesn't it? No, it uses qmake, its own make tool. See qt4-build and qt4-r2 eclasses. KDE and a number of other reverse dependencies of the Qt libs do use cmake. I don't mind having cmake-multilib as well? We could probably move the foreach_abi() function to some more common eclass, like multilib eclass. -- Best regards, Michał Górny -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
It is a simple eclass using autotools out-of-source builds to build
packages for multiple ABIs when multilib is supported.
Use case: xorg packages, ask Matt.
---
gx86/eclass/autotools-multilib.eclass | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 gx86/eclass/autotools-multilib.eclass
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
new file mode 100644
index 000..1a345a1
--- /dev/null
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -0,0 +1,72 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+# @ECLASS: autotools-multilib.eclass
+# @MAINTAINER:
+# Michał Górny mgo...@gentoo.org
+# @BLURB: autotools-utils wrapper for multilib builds
+# @DESCRIPTION:
+# The autotools-multilib.eclass is an autotools-utils.eclass(5) wrapper
+# introducing support for building for more than one ABI (multilib).
+#
+# Inheriting this eclass sets IUSE=multilib and exports autotools-utils
+# phase function wrappers which build the package for each supported ABI
+# if the flag is enabled. Otherwise, it works like regular
+# autotools-utils.
+#
+# Note that the multilib support requires out-of-source builds to be
+# enabled. Thus, it is impossible to use AUTOTOOLS_IN_SOURCE_BUILD with
+# it.
+
+case ${EAPI:-0} in
+ 2|3|4) ;;
+ *) die EAPI=${EAPI} is not supported ;;
+esac
+
+if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
+ die ${ECLASS}: multilib support requires out-of-source builds.
+fi
+
+inherit autotools-utils multilib
+
+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+
+IUSE=multilib
+
+# @FUNCTION: autotools-multilib_foreach_abi
+# @USAGE: argv...
+# @DESCRIPTION:
+# If multilib support is enabled, sets the toolchain up for each
+# supported ABI along with the ABI variable and correct
+# AUTOTOOLS_BUILD_DIR, and runs the given commands with them.
+#
+# If multilib support is disabled, it just runs the commands. No setup
+# is done.
+autotools-multilib_foreach_abi() {
+ if use multilib; then
+ local ABI
+ for ABI in $(get_all_abis); do
+ multilib_toolchain_setup ${ABI}
+ AUTOTOOLS_BUILD_DIR=${S%%/}-${ABI} ${@}
+ done
+ else
+ ${@}
+ fi
+}
+
+autotools-multilib_src_configure() {
+ autotools-multilib_foreach_abi autotools-utils_src_configure
+}
+
+autotools-multilib_src_compile() {
+ autotools-multilib_foreach_abi autotools-utils_src_compile
+}
+
+autotools-multilib_src_test() {
+ autotools-multilib_foreach_abi autotools-utils_src_test
+}
+
+autotools-multilib_src_install() {
+ autotools-multilib_foreach_abi autotools-utils_src_install
+}
--
1.7.12
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Michał Górny mgo...@gentoo.org wrote:
It is a simple eclass using autotools out-of-source builds to build
packages for multiple ABIs when multilib is supported.
Use case: xorg packages, ask Matt.
---
gx86/eclass/autotools-multilib.eclass | 72
+++
1 file changed, 72 insertions(+)
create mode 100644 gx86/eclass/autotools-multilib.eclass
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
new file mode 100644
index 000..1a345a1
--- /dev/null
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -0,0 +1,72 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+# @ECLASS: autotools-multilib.eclass
+# @MAINTAINER:
+# Michał Górny mgo...@gentoo.org
+# @BLURB: autotools-utils wrapper for multilib builds
+# @DESCRIPTION:
+# The autotools-multilib.eclass is an autotools-utils.eclass(5)
wrapper
+# introducing support for building for more than one ABI (multilib).
+#
+# Inheriting this eclass sets IUSE=multilib and exports
autotools-utils
+# phase function wrappers which build the package for each supported
ABI
+# if the flag is enabled. Otherwise, it works like regular
+# autotools-utils.
+#
+# Note that the multilib support requires out-of-source builds to be
+# enabled. Thus, it is impossible to use AUTOTOOLS_IN_SOURCE_BUILD
with
+# it.
+
+case ${EAPI:-0} in
+ 2|3|4) ;;
+ *) die EAPI=${EAPI} is not supported ;;
+esac
+
+if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
+ die ${ECLASS}: multilib support requires out-of-source builds.
+fi
+
+inherit autotools-utils multilib
+
+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+
+IUSE=multilib
+
+# @FUNCTION: autotools-multilib_foreach_abi
+# @USAGE: argv...
+# @DESCRIPTION:
+# If multilib support is enabled, sets the toolchain up for each
+# supported ABI along with the ABI variable and correct
+# AUTOTOOLS_BUILD_DIR, and runs the given commands with them.
+#
+# If multilib support is disabled, it just runs the commands. No setup
+# is done.
+autotools-multilib_foreach_abi() {
+ if use multilib; then
+ local ABI
+ for ABI in $(get_all_abis); do
+ multilib_toolchain_setup ${ABI}
+ AUTOTOOLS_BUILD_DIR=${S%%/}-${ABI} ${@}
+ done
+ else
+ ${@}
+ fi
+}
+
+autotools-multilib_src_configure() {
+ autotools-multilib_foreach_abi autotools-utils_src_configure
+}
+
+autotools-multilib_src_compile() {
+ autotools-multilib_foreach_abi autotools-utils_src_compile
+}
+
+autotools-multilib_src_test() {
+ autotools-multilib_foreach_abi autotools-utils_src_test
+}
+
+autotools-multilib_src_install() {
+ autotools-multilib_foreach_abi autotools-utils_src_install
+}
How docs and nonbinaries get managed?
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sat, 22 Sep 2012 23:44:43 +0200
Luca Barbato lu_z...@gentoo.org wrote:
Michał Górny mgo...@gentoo.org wrote:
It is a simple eclass using autotools out-of-source builds to build
packages for multiple ABIs when multilib is supported.
Use case: xorg packages, ask Matt.
---
gx86/eclass/autotools-multilib.eclass | 72
+++
1 file changed, 72 insertions(+)
create mode 100644 gx86/eclass/autotools-multilib.eclass
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
new file mode 100644
index 000..1a345a1
--- /dev/null
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -0,0 +1,72 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+# @ECLASS: autotools-multilib.eclass
+# @MAINTAINER:
+# Michał Górny mgo...@gentoo.org
+# @BLURB: autotools-utils wrapper for multilib builds
+# @DESCRIPTION:
+# The autotools-multilib.eclass is an autotools-utils.eclass(5)
wrapper
+# introducing support for building for more than one ABI (multilib).
+#
+# Inheriting this eclass sets IUSE=multilib and exports
autotools-utils
+# phase function wrappers which build the package for each supported
ABI
+# if the flag is enabled. Otherwise, it works like regular
+# autotools-utils.
+#
+# Note that the multilib support requires out-of-source builds to be
+# enabled. Thus, it is impossible to use AUTOTOOLS_IN_SOURCE_BUILD
with
+# it.
+
+case ${EAPI:-0} in
+2|3|4) ;;
+*) die EAPI=${EAPI} is not supported ;;
+esac
+
+if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
+die ${ECLASS}: multilib support requires out-of-source
builds. +fi
+
+inherit autotools-utils multilib
+
+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+
+IUSE=multilib
+
+# @FUNCTION: autotools-multilib_foreach_abi
+# @USAGE: argv...
+# @DESCRIPTION:
+# If multilib support is enabled, sets the toolchain up for each
+# supported ABI along with the ABI variable and correct
+# AUTOTOOLS_BUILD_DIR, and runs the given commands with them.
+#
+# If multilib support is disabled, it just runs the commands. No
setup +# is done.
+autotools-multilib_foreach_abi() {
+if use multilib; then
+local ABI
+for ABI in $(get_all_abis); do
+multilib_toolchain_setup ${ABI}
+AUTOTOOLS_BUILD_DIR=${S%%/}-${ABI} ${@}
+done
+else
+${@}
+fi
+}
+
+autotools-multilib_src_configure() {
+autotools-multilib_foreach_abi autotools-utils_src_configure
+}
+
+autotools-multilib_src_compile() {
+autotools-multilib_foreach_abi autotools-utils_src_compile
+}
+
+autotools-multilib_src_test() {
+autotools-multilib_foreach_abi autotools-utils_src_test
+}
+
+autotools-multilib_src_install() {
+autotools-multilib_foreach_abi autotools-utils_src_install
+}
How docs and nonbinaries get managed?
As usual. Installed twice, second time replacing the first ones.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sat, 22 Sep 2012 23:24:46 +0200 Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. to some extent, can't you do the same by unpacking twice to different $S and calling src_prepare/compile/install instead of their autotools-utils counterpart with tweaked $S so that it works with almost every ebuild ? -- this really starts to resemble multilib portage :)
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On 22/09/2012 18:54, Matt Turner wrote: I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. If that's the case, please consider a more broad strategy, in particular: - unforce the multilib flag for the packages that are _built_ for multilib; - make 32-bit binary packages depend amd64? ( whatever[multilib] ) instead of blanketing all xlibs. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sat, Sep 22, 2012 at 6:59 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 22/09/2012 18:54, Matt Turner wrote: I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. If that's the case, please consider a more broad strategy, in particular: - unforce the multilib flag for the packages that are _built_ for multilib; In progress: https://bugs.gentoo.org/show_bug.cgi?id=435094 :) - make 32-bit binary packages depend amd64? ( whatever[multilib] ) instead of blanketing all xlibs. I think this means make 32-bit binary packages' dependencies on amd64 not use the emul- packages? If so, that'd certainly be a component of getting rid of emul-linux-x86-xlibs. It's not in the scope of my project to get rid of /all/ of the emul- packages, but I agree that that is a worthwhile goal.
