On Fri, 26 Jul 2013, Rob Savoye wrote:
> > * DejaGnu has a lot of hardcoded logic to try to find various files in a
> > toolchain build directory. A lot of it is actually for very old toolchain
> > versions (using GCC version 2 or older, for example). The first issue
> > with this is that it doesn't belong in DejaGnu: the toolchain should be
> > free to rearrange its build directories without needing changes to DejaGnu
> > itself (which in practice means there's lots of such logic in the
> > toolchain's own testsuites *as well*, duplicating the DejaGnu code to a
> > greater or lesser extent). The second issue is that "make install"
> DejaGnu is a testing framework, so it makes sense that much of the GCC
> testing logic is in gcc/testsuite/{lib,config}. It was also a decision
> at the time that having a testsuite override existing procs in DejaGnu
> core was a good idea. Now many years later, I think I'd move most what
> GCC needs into the core, especially all the "dg* style of tests.
>
> At one time the thought was DejaGnu was a general purpose test
> framework, but I think at this point in time, it's really just used for
> toolchain testing. (although my Gnash project also uses it) So I think
> tweaking DejaGnu core to be mainly toolchain testing oriented is
> probably a good idea.
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.
For example, it should be possible to completely rearrange the internal
structure of a toolchain build directory without needing to change any
external tools such as DejaGnu. So all the information about the
structure of that directory - how to use -B, -L etc. options to run an
uninstalled compiler, if that's done at all - should be in the toolchain
sources rather than in DejaGnu. (As noted, I think really we shouldn't be
testing uninstalled compilers at all - let "make install" be the single
place that needs to know how to put the different bits of a build
directory together.)
However, it makes sense for DejaGnu to include a parser for diagnostics
that follow the GNU Coding Standards - that's a public interface. But (a)
there should be a better way of handling column numbers than the kludges
in the GCC testsuite at present, and (b) extensibility for such a parser
is still desirable, as new forms of diagnostic location may be added in
future.
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.
--
Joseph S. Myers
jos...@codesourcery.com
