Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)

[Jamie Lokier <jamie@shareable.org>]

Robert Schwebel wrote:
> We have once tried to write our automated test system for embedded
> boards with python and xml; the idea was to have something fancy, new
> and with good code-reuse. In the end it failed because the pexpect
> package we used to do the pattern matching bitrotted so quickly that
> four months later all the fancy tests didn't work any more, because it
> is not part of the python core.
> 
> In the meantime we have migrated our automatic testing stuff to use
> shell, ssh/rsh and kermit. It is rock solid, and the code reuse factor
> is at least as good as with anything else.

It sounds like the basic problem there was using non-core Python.  You
can count on shell, ssh/rsh, kernel - they're stable.  You can count
on Pythong's core language.  But not on pexpect: if you depended on
that, you should probably have copied the code into your own test
system, or written an equivalent.  Easier said than done, I know.

> > Have you felt uncomfortable shipping a package that does use Autoconf,
> > Automake and Libtool, knowing that the scripts generated by those
> > tools are huge compared with the entire source of your package?
> 
> No :-)

It's really disturbed me, sometimes, shipping a package of 50kB source
and 2MB configure+libtool.

> > Have you _written_ Autoconf tests recently?
> 
> Yea, all our packages are autotoolized.
> 
> > Made any shell / shellutils non-portability mistakes in the tests?
> 
> Yea, it happens in ptxdist all the time. People report about problems,
> we add new tests and the next revision works even on Ubuntu :)

Right, so you have no idea about portability of your tests on, say, SCO
Unixserver or IRIX? :-)

> I have no problems with people writing fancy new things. It's just that
> most people who try to do something better than autotools have only a
> fraction of the features.
> 
> Open Source is darwinism: if there is something better, let's use it.
> But compare apples with apples.
> 
> > If you're going to rewrite Autotools using GNU Make, why not ask if
> > another tool would be better, perhaps a tool specially designed for
> > the job?
> 
> Go ahead.

The first part of going ahead is to brainstorm and find ideas and
likely interest...  It's too big (as you rightly note) to simply sit
down and do it by oneself in isolation.

-- Jamie