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
