Re: [testsuite, build] Convert boehm-gc testsuite to DejaGnu (PR boehm-gc/11412)

[Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>]

Mike Stump <mikestump@comcast.net> writes:

> On Jan 5, 2011, at 10:06 AM, Rainer Orth wrote:
>>  I see lots of opportunities for code reuse here: most DejaGnu tools in
>>  GCC started off as a copy of some other tool with search-and-replace
>>  of the tool name and only a few (if any) local changes.  This is a
>>  total mess to understand and maintain and I hope to do something about
>>  this in the future.
>
> :-)  You now can, though, bear in mind, once you have a delegation neuron, and multiple inheritance neurons (ok, stop laughing at me)...  the design of dejagnu is slightly cleaner than at first blush.

My primary issue isn't so much with the design of DejaGnu (rather its
lack of documentation), but with the current uses in GCC: duplicating
the whole per-tool code for every tool with just a few often diverging
changes isn't my idea of a maintainable code base.

> If you've ever seen it wired up to telnet to a terminal server to connect to the serial console on a PC running dos, controled from a real unix machine, to test an entire toolchain (compiler, gdb and so on), you can start to gain some appreciation.  Though, I admit, if you only ever do native testing, the thing is hard to read, convoluted and mysterious.  If someone know of a good programming methodology to allow for the complexity, but hide it for most people, love to have a pointer...  I'd love such a system.
>
> If you ever seen that, and the PC talking to a mips target, and seen it test 5 boards at once, it is sweet.

No doubt about that :-)  I haven't had much use for that myself so far,
coming from a pure Unix background and no need to dive into embedded
envionments.  But certainly the generality helps tremendously, once
you're in the right mindset.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University