This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH]Reduce messages in setup.log
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- To: "Michael A Chase" <mchase at ix dot netcom dot com>,<cygwin-patches at cygwin dot com>
- Date: Tue, 29 Jan 2002 15:55:50 +1100
- Subject: Re: [PATCH]Reduce messages in setup.log
- References: <00c601c1a87f$a49a4090$0d00a8c0@mchasecompaq>
----- Original Message -----
From: "Michael A Chase" <firstname.lastname@example.org>
Sent: Tuesday, January 29, 2002 3:41 PM
Subject: Re: [PATCH]Reduce messages in setup.log
> ----- Original Message -----
> From: "Robert Collins" <email@example.com>
> To: <firstname.lastname@example.org>
> Sent: Monday, January 28, 2002 20:25
> Subject: Re: [PATCH]Reduce messages in setup.log
> > ----- Original Message -----
> > From: "Christopher Faylor" <email@example.com>
> > To: <firstname.lastname@example.org>
> > Sent: Tuesday, January 29, 2002 3:14 PM
> > Subject: Re: [PATCH]Reduce messages in setup.log
> > > On Mon, Jan 28, 2002 at 08:00:36PM -0800, Michael A Chase wrote:
> > >
> > > I don't know how Robert prefers this, but it is customary to
> > > single patch file not a bunch of separate attachments. With one
> > > file you can just say
> > Yes please, one patch is nicer.
> Sorry. I got confused and thought it was the other way around.
No probs. If you have mulitple patchs for _different_things- newlib +
cinstall, or w32api + cinstall, then, yes, multiple files are needed.
> What about the compress_gz.error() and compress_bz.error() messages.
> one is commented out and the bz one isn't. Should they be the same?
> which is preferred? I lean toward writing both as long as they are
I think you've missed the point of the messages. They indicate
incomplete functions, so that the main log shows what the *program*
should have detected.
compress_gz::error returns an internal state error value.
compress_bz::error returns 0!
Likewise for everything that logs to setup.log - it should stay there IF
and only IF it's not properly implemented.
I will happily accept patches addressing the core issues, but not to
hide them :}.
I thought when you initially described this that there where a bunch of
messages that *shouldn't* be going to the log, but until I review the
body of your patches, I can't meaningfully confirm on a per function