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.
