>From: "Clayton Harbour" <[EMAIL PROTECTED]> >Sent: Thursday, September 16, 2004 10:48 AM
>Hi, > >+1 for outputting the target framework > >Gary, would the quiet (-q) switch solve the verbosity issue? >If you are looking for even less output there are other >commandline tools that also add another quiet switch (really >quiet) or a "silent" switch to cut down on messages logged. Sorry it's taken so long to respond to this, but with the holidays, I let this slip. Adding a second level of quiet may have potential. The basic problem with the current implementation of -q is that it doesn't provide enough context. When there's an error from a task, especially an exec task, it just displays the error output but it doesn't display any information about where in the build file the error occurred. No target name, no task name. One possible way to handle this is to have the target log entries cached, and then emit them if and only if there's an error or warning from a task within that target. Another limitation is that the <nant> task doesn't allow me to specify a different qualify. It's often the case that I have some utility operations (e.g. a clean) whose output is totally uninteresting when there's no error. So I might want my top level nant task to be at a normal verbosity level, but when I call <nant target="clean"... I'd like to be able to add verbose="quiet". For that matter, I'd like the verbose attribute everywhere to take "info", "debug", etc. instead of just true and false. Finally, there are some tasks for which the amount of output is just plain silly. xmlpeek is my current pet peeve. It currently emits, at the normal verbosity level, the full file name of the file being examined, the full xpath, and then a second line with the number of nodes found and the full xpath expression again. Given that I'm extracting the five result counts from an nunit result file, this gets tedious real fast. I'd be much happier if the primary design guideline for normal output from nant tasks is to produce exactly one line of output per task, with exceptions to that rule few and far between. The solution task is one that comes to mind as being a justifiable exception, with one line for each "Building ..." event. Gary ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
