This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: make grokfield handle locations
On Tue, 19 Aug 2008, Manuel López-Ibáñez wrote:
> I disagree here. We massively override and work-around DejaGNU since a
> long time ago. No ideal but I think we could almost carry our own copy
> of DejaGNU. We will certainly be able to simplify things and reduce
> duplication of code:
Carrying our own copy of DejaGnu would be crazy. We override very small
parts in a very small area of DejaGnu; nothing to do with all the code for
interacting with many different kinds of targets and remote hosts, for
example.
> 976K /usr/share/dejagnu
> 892K /home/manuel/src/trunk/gcc/testsuite/lib/
If you will compare an SVN checkout of GCC with duplicates of all files to
an installation of DejaGnu with no duplicates, expect biased results.
Almost all of gcc/testsuite/lib/ is entirely specific to the GCC
testsuites; the largest file is target-supports.exp, for example, which is
entirely specific to the tests in the GCC testsuites and the different
sets of targets particular GCC tests are applicable to. (Unfortunately,
core DejaGnu also has a lot of code that would better either be in
individual toolchain testsuites, or not exist at all: code telling one bit
of the toolchain how to find another bit in a build tree, when instead
testing should be run with an installation to a staging directory so the
built-in relocation support in the tools would suffice.)
> There doesn't seem so much upstream activity. If we wait for upstream,
> we are just saying that we will wait forever. The C testsuite would
> still be unable to distinguish between warning/error/notes/random
> output.
My experience is that DejaGnu upstream handles patches promptly and is
easy to deal with; a lack of upstream activity simply indicates a mature
project that doesn't *need* much changing. If a new DejaGnu release would
be of use for GCC, I don't suppose it would be hard to get one made. We
may put temporary workarounds in the GCC code to support working with
older DejaGnu, but being part of the GNU project means working together
with other parts of the GNU project, and putting fixes in DejaGnu if
that's the logically right place, as well as possibly putting workarounds
for unfixed DejaGnu in GCC. Handling of the standard GCS formats for
column numbers and location ranges is obviously useful for core DejaGnu.
I am not saying "wait for upstream", but "send a patch to upstream and
work with the DejaGnu maintainers to get it integrated and a new release
made".
--
Joseph S. Myers
joseph@codesourcery.com