This is the mail archive of the
mailing list for the GCC project.
Re: [web] Revised instructions for testing using a simulator
- From: Janis Johnson <janis187 at us dot ibm dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Wed, 25 Sep 2002 10:14:39 -0700
- Subject: Re: [web] Revised instructions for testing using a simulator
- References: <20020924235003.GK5021@codesourcery.com>
On Tue, Sep 24, 2002 at 04:50:03PM -0700, Zack Weinberg wrote:
> Here is a revised version of simtest-howto.html. The two biggest
> changes are: First, I replaced the directions for creating a combined
> tree with hard links -- which in my experience has never worked
> properly -- with directions for checking out a pre-combined tree from
> the "uberbaum" repository. Second, I augmented the table of
> verified-to-work simulator targets into an exhaustive list of
> simulator targets that in principle should work, replacing all the
> confusing advice about how to guess target and board names.
The current instructions work for me. I update the gcc tree using
contrib/gcc_update, and the the others using "cvs update", although I'll
try using "cvs co" instead. (Is there something like gcc_update for
updating the src tree, or things that can go wrong because of the lack
of such a tool?) After an update I remove the old combined tree (full
of hard links) and create a new one. The new information about checking
out directories that don't take as much room is good.
I'll stay out of the discussion about where it's appropriate to get CVS
trees. If the decision is to stay with the currently suggested ones and
create a combined tree using hard links, there should be a new section
explaining how to update the trees and the combined directory. I can
write up how I do it. Otherwise I'll start using the uberbaum myself.
The list of all targets that can be tested with a simulator is very
useful, but does the new "Architecture" column really add anything?
There are only a couple of architecture names that are different in the
target, and those could be pointed out in the "Comment" column.
The "Verified" column could have a link to archived test results. Even
if those aren't updated very often, knowing which tests failed at one
time is more useful than knowing the number of tests that failed at one
To make things a little more clear, you could have "parent=`pwd`" at
the beginning of the instructions for "Create a combined tree", and
"cd $parent" at the beginning of the instructions in each of the other
IBM Linux Technology Center