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
