Re: [Qemu-devel] mksh on Slackware (was Re: CVS: herc.mirbsd.org: src)

[Thorsten Glaser]

enh dixit:

[ mksh testsuite ]
>have you considered using sh instead? :-)

Not pure sh, that’s nowhere near enough. Maybe mksh. But if
the one just built has issues, that may mask it. If another,
you’ve got hen/egg problems.

Maybe C. But then, (cross-)building a C program to test another
one just built *may* (or may not) be more susceptible to errors
than using a completely separate tool.

No, I’m not happy with the current testsuite driver, but it’s
there, it’s reasonably portable, and does its job, after some
prodding (and I still don’t speak Perl).

>(there's no perl on Android, which makes running the mksh tests
>impractical. one can *build* perl for Android, i'm led to believe, but

I’ve successfully (modulo the things that just didn’t exist,
or didn’t work with toolbox) run the testsuite on Android
(on the emulator) once, with a native Bionic perl.

Nowadays, I’d probably just get a Linux/ARM box (Debian
poterbox would be superb, except I retired from Debian
recently), build a native Perl against dietlibc or musl,
statically, then copy that over to Android, as it only
relies on the kernel, and this is enough for the testsuite.

Another idea we will have to try out: check if the testsuite
can be run on the build system (instead of the target), using
ssh (or adb shell) to invoke the to-be-tested utility on the
target. Con: we’d probably need to NFS-mount or rsync the
directory tree. But maybe something the *WRT people are also
interested in. (Or we could move file generation to the target
as well. Needs more hacking work in the testsuite driver.)

Anyway, this is still enough short-term.

bye,
//mirabilos
-- 
“The final straw, to be honest, was probably my amazement at the volume of
petty, peevish whingeing certain of your peers are prone to dish out on
-devel, telling each other how to talk more like a pretty princess, as though
they were performing some kind of public service.” (someone to me, privately)