On 07/26/2013 10:37 AM, Joseph S. Myers wrote:
> Anything in the core needs to avoid obstructing toolchain changes. People
> typically test with the installed DejaGnu from their OS, and the OS itself
> may well be a few years old (e.g. Ubuntu 10.04), so it's undesirable for
> an enhancement to the GCC testsuite to require a new version of DejaGnu.
> This means clean extensibility, and avoiding DejaGnu hardcoding things
> that are not stable public interfaces.
DejaGnu is basically stagnant because most people consider the pain of
any improvements too great to change anything. If I launch off on a
DejaGnu 2.0, my thought is the existing release wouldn't go away. Many
distributions ship multiple versions of some applications. Any changes
to DejaGnu would likely live in a branch for a long time, but would be
usable by anyone interested in better functionality. Yes, an actual
design and defining public interfaces would be a good idea. Currently
DejaGnu has many arbitrary APIs and settings, all created without a
whole lot of thought other than working around or fixing a problem.
I also realize that any major changes to DejaGnu will require
corresponding changes in the testsuite support code. I'm completely
aware of how much work this would be having written much of it... There
would have to be backward compatibility maintained for a considerable time.
> Right now, DejaGnu has lots of toolchain stuff in the core ... toolchain
> stuff for building Cygnus trees 20 years ago rather than what's useful
> now. It's not that much better if a DejaGnu version released in 2013 and
> used for testing in 2017 has things in it that are good for testing 2013
> toolchains and get in the way for testing 2017 toolchains.
I'd agree there is lots of crufty support for things like the old
Cygnus trees that could be removed. Ideally I'd prefer to explore
people's ideas on what would be useful for testing toolchains 5-10 years
from now. Me, I want something not dependent on a dying and mostly
unmaintained scripting language that nobody likes anyway (the current
working idea is to use python). I also want to be able to compare test
results in better ways than diffing huge text files. I'd like to compare
multiple test runs as well in a reasonably detailed fashion.
- rob -
