public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Carlo Wood <carlo@runaway.xs4all.nl>
To: egcs@cygnus.com (egcs@cygnus.com)
Cc: law@cygnus.com
Subject: egcs testsuite & dejagnu : A special case?
Date: Thu, 25 Jun 1998 18:53:00 -0000	[thread overview]
Message-ID: <199806251527.RAA04581@jolan.ppro> (raw)

Hey all, I love working in this team :).
Quite a change from the seven years I worked
on the undernet ircd project: Here there are
actually others that do something too! :)

But back to serious work:

----

My self-assigned task of checking how well
the egcs testsuite works with dejagnu has
lead to a the following conclusion on which
I'd like to get some feedback from you:

The latest dejagnu (980528) did address the
problem that was temporally fixed with the
lookfor_dir_with_trigger.patch (to be applied
to dejagnu-971222 only thus).

However, as already reported by H.J. Lu,
dejagnu-980528 is broken again (even with
the lookfor_dir_with_trigger.patch because
something else is broken now).

I investigated this new problem and found that
it basically is the result of the fact that
dejagnu is written to test other packages,
other packages that need a compiler to be
compiled, but that definitely are not the
compiler itself.

The problem, when needing the package itself
to compile the package (testsuite executables),
has not been addressed in dejagnu.

My feeling is that this is not really a problem
of dejagnu: We can't expect them to hardcode
support for all the compiler cases into dejagnu,
not unless there is a simple solution that makes
egcs take care of this "special handling".
For example, dejagnu sets $gccpath to the path
of the installed compiler.  I think it is the
responsibility of egcs to explicitly make sure
that it is set to the correct directory of the
package being tested (egcs); and not the
responsibility of dejagnu to detect it is now
testing a compiler package.

I am more then willing to write the small changes
for egcs to make it work smoothly, but I'd like
to hear a "go" from you before I do :).
These patches will be logical, but only if you
accept the idea that testing a package that is
a compiler is a special case.

Comments please?

Carlo Wood

carlo@runaway.xs4all.nl


             reply	other threads:[~1998-06-25 18:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-06-25 18:53 Carlo Wood [this message]
1998-06-26  2:49 ` Manfred Hollstein
1998-06-29 22:34 Mike Stump
1998-06-30 15:15 ` Craig Burley
1998-06-30 14:46   ` Jeffrey A Law
1998-07-01  0:54 Mike Stump
1998-07-01  7:26 ` Craig Burley
1998-07-01 20:20   ` Jeffrey A Law
1998-07-02 11:02   ` Carlo Wood
1998-07-03  0:12     ` Craig Burley
1998-07-03  0:50       ` Carlo Wood
1998-07-03  8:38         ` Craig Burley
1998-07-03  9:35           ` Carlo Wood
     [not found] <199807031310.PAA24690@jolan.ppro>
1998-07-03 15:29 ` Craig Burley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199806251527.RAA04581@jolan.ppro \
    --to=carlo@runaway.xs4all.nl \
    --cc=egcs@cygnus.com \
    --cc=law@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).