From: Mike Stump <mrs@apple.com>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: Andreas Schwab <schwab@suse.de>, Phil Edwards <phil@jaj.com>,
Andreas Jaeger <aj@suse.de>,
Zack Weinberg <zack@codesourcery.com>,
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>,
gcc@gcc.gnu.org
Subject: Re: Problems with "make check"
Date: Thu, 03 Apr 2003 19:26:00 -0000 [thread overview]
Message-ID: <4F3F9008-65FE-11D7-B09F-003065A77310@apple.com> (raw)
In-Reply-To: <Pine.BSF.4.53.0304031037040.60818@acrux.dbai.tuwien.ac.at>
On Thursday, April 3, 2003, at 12:38 AM, Gerald Pfeifer wrote:
> On Thu, 3 Apr 2003, Andreas Schwab wrote:
>> But then, what's so bad about make -k check?
>
> One can forget the -k? ;-)
>
> Seriously, I believe I recall several reports/discussions on that here,
> and while it is definitely a user error, if we can somehow avoid it,
> why
> not do that?
Let me state the obvious. If the testsuite doesn't have any unexpected
failures, it will return success. libstdc++ used to not fail. I think
we should move to the point where unexpected errors on primary
platforms won't be allowed to exist (48 rule imposed by a dispationate
cronjob).
For example, uninstalled locales need to be detected, and tests that
fail because of them, should be fixed to ignore that situation, or
report untested.
next prev parent reply other threads:[~2003-04-03 18:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-28 8:47 Richard Kenner
2003-04-02 22:25 ` Zack Weinberg
2003-04-03 6:18 ` Andreas Jaeger
2003-04-03 6:24 ` Zack Weinberg
2003-04-03 6:32 ` Andreas Jaeger
2003-04-03 8:30 ` Phil Edwards
2003-04-03 11:30 ` Andreas Schwab
2003-04-03 11:49 ` Gerald Pfeifer
2003-04-03 19:26 ` Mike Stump [this message]
2003-04-03 19:11 ` Tom Tromey
2003-04-03 20:19 ` Phil Edwards
2003-04-02 22:47 Richard Kenner
2003-04-03 13:02 Richard Kenner
2003-04-03 14:04 ` Andreas Jaeger
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=4F3F9008-65FE-11D7-B09F-003065A77310@apple.com \
--to=mrs@apple.com \
--cc=aj@suse.de \
--cc=gcc@gcc.gnu.org \
--cc=kenner@vlsi1.ultra.nyu.edu \
--cc=pfeifer@dbai.tuwien.ac.at \
--cc=phil@jaj.com \
--cc=schwab@suse.de \
--cc=zack@codesourcery.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).