This is the mail archive of the
mailing list for the GDB project.
Re: Changing the C/C++ compiler for gdb testsuite runs
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Richard dot Earnshaw at arm dot com, Michael Snyder <msnyder at redhat dot com>, gdb at sources dot redhat dot com
- Date: Fri, 11 Jan 2002 15:38:35 +0000
- Subject: Re: Changing the C/C++ compiler for gdb testsuite runs
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > But since they don't come from the same CVS tree, I can't see how to do
> > that cleanly without dicking around with the common code directories such
> > as libiberty and include -- experience has shown that with the public CVS
> > repositories that is fraught with problems. I have done it in the past,
> > but it breaks the principal that the sources you are testing are the
> > sources you are committing, so it isn't really a viable option.
> Is the experience recent? At present mechanical processes help to
> ensure that liberty and include are kept very much in sync (typically
> only hours separate commits).
Well it can happen at any time when one product is coming off a branch and
the other of the trunk (or a different branch). When gcc forks (or gdb
forks) there is bound to be divergence (for obvious reasons).