| Summary: | ARCH should be calculated rather than hardcode | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | SpanKY <vapier> |
| Component: | Core - Configuration | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | embedded |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I think what you really want is make.conf to be "selectable" and the profile to be "selectable". So that when cross compiling you can use an alternate configuration and profile that suits the target. yes, that would work too ... however, it's been my impression that that kind of feature support is a long way off
this is realizable now (i've switched our toolchain to using $(tc-arch) which parses ${CHOST} with a similar case statement to what ive shown here)
we'll categorize this under the 'specify profile for build' bug |
i propose ! if $ARCH is not defined in the normal envvar lookup path (make.conf/profile/environment/etc..), then it should be calculated ... first based upon CTARGET (if defined) or CHOST (if CTARGET is not defined) rational being that currently, when one is cross-compiling, `use $ARCH` and `$ARCH == ""` statements could add/remove code/features when it shouldnt be here's a simple bash case statement to do this (note, this assumes linux based systems at the moment, but these are the only systems where we will be punting $ARCH for now ... non-linux systems will have to continue setting $ARCH): case ${CTARGET:-${CHOST}} in alpha*) ARCH=alpha;; arm*) ARCH=arm;; hppa*) ARCH=hppa;; i?86*) ARCH=x86;; ia64*) ARCH=ia64;; powerpc64*) ARCH=ppc64;; powerpc*) ARCH=ppc;; sparc*) ARCH=sparc;; s390*) ARCH=s390;; sh*) ARCH=sh;; x86_64*) ARCH=amd64;; esac