Re: Autobuilding with cross-compiler to solve m68k woes?
James,
Quoting James Troup <james@nocrew.org>:
> > [ Another inevitable cross-compilation suggestions ]
> No, no, no. Cross compiling is NOT the answer. I would rather see
> m68k dropped than having it cross-compiled. Cross-compiling is evil,
> does not work all the time and is quite simply not the answer...
> Buildd has many faults, but one of it's strengths is that it is
> perfectly scalable out of the box. If an architecture is really too
> slow, you add more boxes. The fact that there is currently only one
> buildd per architecture is pure happenstance and _not_ a limitation of
> buildd (I know because I use to run m68k/buildd#2). It doesn't matter
> if we have something as slow as a z80 as long as we have enough
> net-connected slow-as-heck boxes, they could keep up.
What if we had the means of reliably determining which packages could be
cross-compiled, and which needed to be compiled on a native system? Would that
make cross-compiling a viable option?
I guess I don't see why you believe that 'cross-compiling is evil'. Every port
to a new architecture has to start out with cross-compiling, and I don't think
anyone believes porting is evil. Why is it evil to use cross-compiling when the
software running on the architecture is too large to be compiled on that
architecture?
After all, there's a limit on the parallelizability of buildd in that you can't
readily split the building of any single package across multiple machines. What
if you had something as slow as a Z80 that was terrible at compiling, but which
made a great architecture for a webserver? (Ever tried to compile anything on a
Cobalt? :) What if compiling Apache natively on that architecture takes >>
24hrs? To me, that seems like a sound argument for using cross-compiling to
support such a platform.
Steve Langasek
postmodern programmer
Reply to: