This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs testsuite & dejagnu : A special case?
- To: mrs at wrs dot com
- Subject: Re: egcs testsuite & dejagnu : A special case?
- From: Craig Burley <burley at gnu dot org>
- Date: Tue, 30 Jun 1998 09:44:28 -0400 (EDT)
- Cc: carlo at runaway dot xs4all dot nl, egcs at cygnus dot com, law at cygnus dot com
- Cc: burley at gnu dot org
>We all agree here. Cleanliness says that we should use generic
>interfaces with as little built in knowledge of the compiler specifics
>as we can. dejagnu however is not exactly a model of cleanliness.
This reminds me of a thought I had the other day while not on-line.
I've gotten the impression (not knowing much about how all this
testing stuff actually works at this point) that some of the problems
we've run into are due to attempting to be able to test an
*uninstalled* compiler as well as an installed one. Is that true?
(An uninstalled compiler differs in ways including that the `gcc'
command is named `xgcc' to avoid conflicts when $PATH contains `.',
I assume; the default directory to search for the `specs' file is
the yet-to-be-installed-into directory instead of the same directory
the `xgcc' command is being run from; and other stuff that maybe
even the `-B' and `-L' don't fully ensure makes for identical
behavior running the uninstalled version exactly the same as
running it will be once it's installed.)
Certainly it's often the case that I want to run tests of my own
(using my own primitive test suite, or just try out a submitted
test case or something), and I've done a variety of things over
the years to cope with the fact that I want to try out a *built*,
but not *installed*, version of the compiler.
(On my old 486/33, I had a bunch of shells scripts installed in
/usr/local/bin that'd invoke the compiler in canonical places
in my home directory, using the appropriate -B and -L switches,
etc. Now that I have a much faster system, I just specify
a unique --prefix and do "make install" each time it seems
appropriate, which takes only about a minute, but not everybody
has that. And, I admit it's tedious to keeping typing full
pathnames like `/develop/g77/0.5.23/bin/g77' to specify which
version of the compiler I want to run. That's a minor problem
compared to back when I couldn't really maintain more than two
versions, though!)
It occurred to me that, maybe, we could avoid much of this trouble
by, instead of working around the differences between installed
and uninstalled compilers *externally* (to the compiler itself,
that is), we could define a new interface to the compiler *itself*
that, when invoked, amounts to saying "I'm invoking the *uninstalled*
compiler", and leave all the mucking about with pathnames and such
to the new interface.
So, what I'm suggesting is that we teach the compiler *itself* (as
a complete package) to hide all the details of invoking an
uninstalled version of itself "consistently" within some kind
of published interface that everyone can use, safely.
For example, what if we had the build process automatically build,
but not install (obviously), shell scripts containing the appropriate
options and pathnames, wrapping around invocations of `xgcc', `g77',
`g++', and whatever else people normally invoke as commands in an
installed compiler. E.g.:
gcc-ui would be a shell script (command) built to automatically
do `$(objdir)/xgcc -B$(objdir)/ -L$(objdir) $*', where $(objdir)
expands to the absolute pathname of the build directory.
g77-ui would be a similar script but invoke `$(objdir)/g77' instead.
g++-ui ditto for g++.
And so on.
`-ui' just stands for `uninstalled', but maybe a better naming scheme
can be used. Or maybe a distinct option, like `-funinstalled', would
be cleaner, though I somehow think that wouldn't fit cleanly into
how most external uses of gcc already operate (they might assume
that the variable meaning "command to invoke gcc", e.g. $(CC), is
really just a single command with no options).
Does this idea have any merit? Offhand it seems fairly simple to
implement, and, once we change the pertinent tools (egcs top-level
Makefile such as when doing `make check') to use them, could really
reduce the maintenance headaches we seem to be having with trying
to do useful work on uninstalled compilers.
tq vm, (burley)