Brian Harring schrieb:
You need a glep here frankly; per the norm, if you want things to move
faster, then put in time- aka, generate a patch against PMS, write a
patch for portage, etc, you get the idea. The bit re: a PMS patch is
mostly that in looking at your proposal... well, I personally don't
want to write that patch (nor do I suspect ulm/ciaran do either).
As written earlier, a patch for portage exists already (just the diff
between multilib and master branch of portage).
Now, in addition, a GLEP draft for cross-compile support in
multilib-portage.
One thing to note; this has been posted for all of 2-3 days; that's
not exactly much time for 1) people to comment, 2) people to frankly
comprehend the quite dense description you wrote.
This may be true, but as you may have seen afterwards, beside the
responses to my mail about planned council asking, there have not been
any further responses, so the relatively short time since my mail doesnt
seem like the reason for missing responses.
Please write a glep covering details of the implementation,
background, preferablly why this route over others. Bluntly... clue
everyone else in rather than hoping they'll just sign off on a fairly
opaque list of things. :) It'll be useful for dev education also-
which is a bit of a requirement for stuff of this sort considering
it's not going to be a magic deploy/shit works everywhere situation I
suspect.
See attached GLEP draft.
Would also be useful getting commentary from crossdev folk considering
your solution is intended to be (best I can tell) full cross
compilation support, and they've been leading that front for many,
many years.
There is an important difference between my cross-compile support for
multilib profiles and crossdev: My suggestion works with the default
toolchain, which itself is able to cross-compile for other targets (like
the amd64/multilib gcc is able to create 32bit libs), while crossdev is
using a different toolchain for the targets.
Of course, if someone from crossdev maintainers wants to comment, he is
free to do so.
--
Thomas Sachau
Gentoo Linux Developer
GLEP: XXX
Title: Crosscompile support for multilib profiles
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/07/19 12:09:20 $
Author: Thomas Sachau to...@gentoo.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 24 Jun 2012
Post-History: 2-Jun-2003
Abstract
Currently, multilib profiles like amd64 do support other targets, but there
is no simple way to build packages for those seperate targets. A workaround
for this issue are emul packages, which contain precompiled 32bit libs.
This GLEP extends the package manager to allow the user to build packages
from source for targets supported by the profile and toolchain.
Motivation
==
There is no way to build packages for other then the default target also
the profile and toolchain do support them. For amd64, there are precompiled
emul packages, which only support a predefined subset of packages, are not
compiled with the respect for the user USE or comiler flags and tend to
become outdated due to the amount of packages they include.
Specification
=
This GLEP will extend the functionality of package managers with a future
EAPI. With this EAPI, users will be able to select additional or different
targets per package by adjusting the additional USE flags. Ebuilds
themselves dont have to be modified to support this. If a dependency does
support the future EAPI, depending packages may require a specific target
to be enabled via use dependencies.
Exmaple:
profile: amd64/multilib
package dev-libs/a uses the future EAPI
packge app-misc/b requires 32bit libs from dev-libs/a
It can now define this in the dependency section as following:
DEPEND=dev-libs/a[multilib_abi_x86]
Rationale
=
The proposal does add USE flags for each supported target ABI. This allows
the user to select per package, if he wants to compile it for the default
target, additionally for another target or just for another target.
An alternative would have been a global variable defining this support for
all packages at once. This was not done, because it would force the user
to either build all (even unneeded packages) or nothing with additional or
different target support without the ability to choose on a per package level.
The proposel does add a USE flag called abiwrapper to control the
behaviour for binaries. If this flag is enabled and there is a none-default
target enabled, the binaries for each target are preserved and installed
with their target as suffix. A symlink is created for the binary name to a
wrapper, which does execute the real binary based on a set environment
variable. Following alternative implementations have not been selected:
* no wrapper: This would mean, that the installed binaries change, depending
on the selected targets. Since some binaries have target
