----- Original Message ----- From: "Martin Aliger" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]> Sent: Friday, May 07, 2004 2:48 PM Subject: Re: [nant-dev] verbosity
> Hi Gert, > > hm - I read your mail twice and hope I catch it now :-) > > > I had a closer look at your patch, and I'm not sure how to proceed now. > > > > The verbose attribute and the loglevel (or whatever its called) actually > > serve a different purpose (your patch introduced a regression here) : > > > > - the verbose attribute is used to increase the logging level of verbose > > message to info, in order to have verbose messages output in the build log > > when the project is only allowing info (or higher) messages to be ouput > > > > - the loglevel attribute controls the loglevel a message should at least > > have for it to be output in the build log > > Yes. I see it same way. > > > > Now, we should ask following questions : > > > > - do we allow the LogLevel of a task to be set to a value higher than the > > threshold of the project, or should we ignore values higher than the > > thtreshold of the project ? > > a/ Lowering loglevel below project treshold (so allowing more messages to > output) is nice for debugging just one task. It is handy to run nant in > normal mode and override that task to debug level. I agree that this would be nice to have, but right now the logger is responsible for the respecting the threshold, not the tasks themselves. > > b/ Raising loglevel up to project treshold could supress some unwanted > messages even in verbose mode. Could be handy in some tasks/functions which > internally call other tasks/functions but do not want its output to bother > user. Definitely. This one will be very useful, and easy to implement. > > I see both cases handy and mine +1 goes to allow both overrides. But I see > that it could be a little tricky with quiet/verbose/debug command switches > (some messages in quiet mode!) > > > Next idea: allow just b/ and change meaning of -debug to allow also a/ > override? Mine goal is to enable one-task debugging and eliminate need to > scroll several screens and find that few lines in it. Maybe -debug<project > threshold level> could be great (so -debug4000 writes all > warnings+errors+allow overrides) Not sure if this is something we can/should do ... > > > > - if we allow the LogLevel of a task to be set to a value higher than the > > threshold of the project, then should we have the LogLevel property return > > the effective loglevel (meaning the highest common log level). eg. if the > > loglevel attribute is set to Verbose, but the threshold of the project is > > set to Error, should the LogLevel property then return Error (as that is > the > > effective log level) ? > > Yes - I think it should return effective loglevel. Other question is what is > effective. Highest common log level do not allow message (a) override what I > describe above. I've thought about this some more, and perhaps we should just have the LogLevel (or Threshold) property return its value as it and add a separate method to query the effective logging level (eg. IsLogEnabledFor(Level)). > > > - should the LogLevel take into account the value of the Verbose property > ? > > Should it return Level.Verbose when it was actually set to Level.Info, but > > Verbose is set to tue hereby causing messages with level Verbose to be > > logged as Info messages ? > > Not sure here. Maybe we could better implement it in consistent way so > Verbose property will "translate" verbose messages into info messages and > loglevel remains the same. Yeah, ok. > > Another view: > loglevel/treshold/verbosity or whatever we call it - we want to supress > some messages and alow some others. One property for this should be enough. > I'd prefer to have all messages have its hardcoded level (so - > error/warning/info/verbose/debug) and only thing what is changing is > "threshold" which messages should output. This is consistent with log4net I > think (if we ever in future use log4net for common messages) So, you'd vote for removing the Verbose property/attribute ? If we do not want to allow (or can't allow) tasks to output messages with a level that is lower than the project's threshold, then users will need to start NAnt in verbose mode to be able to view verbose messages ... Not sure if this is something we want to do ... Gert PS. I'm taking this discussion to the list ... ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
