[Toybox] make allyesconfig breaks tests

[Rob Landley]

On 02/10/2012 12:42 PM, Elie De Brauwer wrote:
> Hi all,
> 
> I've been doing some further playing around, and found out that a make
> allyesconfig (which also introduced the unused variable warnings)
> actually breaks the make test. This is because in scripts/test.sh on
> line 14 it says: PATH=.:$PATH and later on sed is used.

Yup.  To be expected at the moment.  The "default y/n" status indicates
whether or not a command implementation is in a usable state, so
defconfig builds everything that can reasonably be expected to work.

I wrote most of the busybox sed command, but it's not entirely my work
so I can't just port it.  I have to write a new one.  (Mount/umount are
in a similar state: I already did this and know how, I just have to find
the free time to redo it...)

> However the only thing the current sed implementation (which make
> allyesconfig turns on) does, is a printf("Hello world\n"), meaning
> several variables (which were created by the use of sed) end up
> containing Hello world. And as a result the remainder of the script fails.

I added a stub for sed and was working on it shortly before I mothballed
the project.  I'm just now getting back around to working on it, and had
some cleanup to do.

> I think the bottomline question is whether we want our own dogfood to be
> eaten during testing or whether we rely on parts of the host system. If
> we want to run tests on target then we need to follow the eat our own
> dogfood option.

Dogfood, definitely, but allyesconfig isn't currently worth testing.
Once I fill out the backlog of stubs, it should be again.  In the
meantime, test defconfig.

> A quick workaround to get the allyesconfig test functional again
> consists out of calling sed directly (/bin/sed), this follows the
> test-on-host-philosophy. A dumb patch is in attach, but it's not a
> decent solution.

A quick workaround is to delete the sed stub until I've got something
worth checking in, but I'd rather implement it properly instead.  But
probably not this weekend.

> (Btw, also related with the sed issue, wrappers/ contains tac, unix2dos
> and dos2unix, these script rely on sed, this implies somehow that
> enabling/copying over these wrappers triggers the inclusion of sed,
> which isn't there today either. )

It's not currently installing them in a target system, either.  I
haven't quite worked out how I want to handle that, but am deferring it
until I get sed implemented.

My current test environment is Aboriginal LInux
(http://landley.net/aboriginal) which builds the smallest/simplest
self-bootstrapping environment, currently based on busybox.  (That's why
I started working on busybox in the first place, extending it to work in
a development environment that could rebuild itself from source code,
kernel, libc, toolchain, and all.)  It's now to the point where it
builds to completion for many different (arm, mips, powerpc, i686,
x86-64, etc), but then I can boot the result under qemu and natively
build the whole of linux from scratch under it.  (This process is
entirely automated, and can run from a cron job.)

I recently added a TOYBOX option to aboriginal linux that installs the
toybox defconfig commands over the busybox commands, and I have
infrastructure that then logs all the command lines called out of the
$PATH so I can see what the build is actually _using_.

My most recent blog entry about this was:

  http://landley.net/notes-2011.html#29-12-2011

Last weekend, when I plugged in defconfig toybox to the aboriginal linux
build, sort and xargs segfaulted during the build, and the resulting
toolchain died with an internal compiler error partway through the
build.  I've since fixed the sort bug, but still need to do the xargs
one.  That's what's holding up the toybox 0.5 release.

I'm sort of doing an informal feature freeze until I get the release
out: the contributions are great but I want to checkpoint the project
state with a release before merging them, and I need to fix the bugs so
the commands work in the aboriginal build before doing a release.

(That build is my big test.  The test suite is nice and needs lots more
stuff added to it, but putting real world data through the commands
finds all sorts of bugs...)

Rob