On Wed, Jun 06, 2007 at 02:28:25PM -0700, Ed Swierk wrote:
> There is something to be said for target emulation or
> run-parts-of-the-build-on-hardware solutions, but I think the
> best answer is one where any available host can compile Fedora
> for any target.
Isn't that exactly what we'd get with target emulation? Any available
host that can run an emulator could then build all of fedora Fedora
for ARM or PowerPC or whatever.
I think that something like qemu-system-arm is probably one of the
very few ways of speeding up package builds while still being able
to guarantee that the result is 100% identical. (Although my
fastest ARM boxes are probably faster than doing it via qemu.)
For the Debian armeb port, what we did for a while is to run all
package builds natively, but to have the actual compiling be done
on a fast x86 box, by making the ARM board use distcc, and having
the x86 box run distccd with an ARM cross-compiler. I don't think
this generates 100% identical binary code, but it should still be
functionally equivalent.
Supporting cross-compiling would be great, but having spent a
several
weeks fighting with Python and its libraries last year and losing, I
suspect scouring the other nine zillion Fedora packages for
cross-correctness is no small exercise, not to mention battling new
bugs as they crop up.
I would fully agree with the sentiment that cross-compiling the entire
distro as _the_ standard way of maintaining the arch package repository
is not a realistic scenario and will likely never be. Preferably, I
would like to just keep doing this entirely natively.
It appears a lot less effort to maintain a set of patches to make some
limited subset of packages (say, 300 packages) cross-compilable,
though. In some cases, we'll have to do this anyway.
That said, there is certainly room for both approaches, and getting
even a small number of packages to cross-compile might be enough for
many embedded applications.
ACK.