On Thu, 03 Jan 2013 11:44:58 +0100 Thomas Sachau <[email protected]> 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 <[email protected]> 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 tricky. Even with what I've written above ? Why ? > 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. You don't need an EAPI then, just get your changes merged in portage. Alexis.
