=== ----- Original Message ----- From: "Michael A Chase" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 29, 2002 3:41 PM Subject: Re: [PATCH]Reduce messages in setup.log
> ----- Original Message ----- > From: "Robert Collins" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, January 28, 2002 20:25 > Subject: Re: [PATCH]Reduce messages in setup.log > > > ----- Original Message ----- > > From: "Christopher Faylor" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > 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 provide a > > > single patch file not a bunch of separate attachments. With one patch > > > 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. The gz > one is commented out and the bz one isn't. Should they be the same? If so, > which is preferred? I lean toward writing both as long as they are going to > setup.log.full. 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 basis. Rob