On Mon, Jul 11, 2005 at 08:28:05PM +0930, Brett Lymn wrote:
> On Sun, Jul 10, 2005 at 03:38:29PM -0400, Nick Holland wrote:
> >
> > If your machine is too slow to do what you need it to do, you need a
> > faster machine. Cross compiling is not the answer to your problem.
> >
>
> Not so Nick. There may be some cases where you deliberately have a
> slow machine for reasons of power consumption/heat disappation,
> perhaps a fanless machine, you want to update.
A fanless machine.
uh-huh.
Let's see...what possibly fanless, low-power platforms do we have?
cats..ok, sure, but not very slow.
i386..ok, but you can native build on on Really Fast Stuff.
zaurus..almost defendable. but not really.
The lowest power machines ('cept for cats/Zaurus) can be native built on
another machine easily. And cats/zaurus just isn't that slow. If you
were foolish enough to install a machine that you can not maintain to
your satisfaction, you deserve what you get.
> Or just that the
> fastest machine in the architecture you are targeting falls way behind
> current machines (SPARC vs current P4, say).
What isn't obvious is why this means it is good to cross build.
> Telling someone to use a
> faster machine is a trite answer but, in some cases, it is simply
> infeasible.
Unproven.
Some machines are too slow to have in production use. Cross-building
doesn't change that.
My employeer is currently throwing away machines faster than the fastest
single CPU SPARC system (and lower power draw, too)...if you are running
on a slow SPARC, you are doing it out of love of the machine, not out of
"best machine for the job". Nothing wrong with that, but if you love
the machine, you might as well love the whole machine. If you can't
stand the compile time, it is time to move on.
> > Which would you rather have developers doing...adding new
> > features, cleaning up code, improving existing operation...or helping
> > <insert adjective here> users do silly things with no value added to the
> > project?
> >
>
> "improving existing operation" you just said it there. Cross building
> means that you are not bound by the limitations of the target
> hardware. This actually impacts the developers more than anyone else,
> especially during the release cycle. Imagine having to restart a
> build that takes literally days to complete because what seemed to be
> a benign change that fixes a bug causes an architecture specific build
> error.
Why imagine? Been there, done that. Repeatedly. DAYS.
If I couldn't stand it, I'd toss all the mac68k stuff out.
Working on an old, slow machine is not a necessity anymore. If you
aren't doing it for fun, move on. If you can't laugh at release time
when someone hands you the SECOND "after the last minute" security fix
for an app requiring a rebuild and re-release, you are using the wrong
platform.
> In a cross build environment the impact could be as little as
> a hour or two instead of days. It means developers can do more stuff
> because they are not waiting for the slower processors to grind
> through a compile.
Funny, from what I've seen, when our good developers are waiting for a
slow machine, they work on something else on a different machine or a
different platform. Some of our best people work on very slow systems.
Pretending for a moment your argument had merit, what if the cross build
works but the native build does not? What if your slow platform has a
platform-specific instability that shows itself on native building?
Been there, done that, too.
We've seen what cross-building means for other projects. We've seen
what native building does for OpenBSD. We rather like our choice. We
have seen what it does for quality.
Nick.
