Regardless of future implementation tasks, would anyone object if I enhance the ExternalProgramBase to indent output from called programs? :)
I agree that we need a more powerful logging system, but as things stand right now, we have a half-decent one that gets the job done. Once 0.8 is finally released, we can start to look at things like this.
BTW, anyone have anything urgent that needs to go into the release? If not, I can take what we have now and put it out as a release candidate for 0.8. I think we're in a good enough place to at least let people give it a whirl.

Simon Steele wrote:

Hi,


[see below] Is that the kind of thing you had in mind?

In a way, yes. I was under the impression that all the tasks currently use
the Log class to write their build output, and it might be nice to extend
this to output something a little better defined:

<build-results>
<target-output name="target-name" result="[success|failure|...]">
[if verbose]
<parameters>...</parameters>
[/if]
<info>Some info.</info>
<info>Some more info.</info>
<warning>This is a warning.</warning>
<info>even more info.</info>
<error class="fatal">Could not build...</error>
</target-output>
<summary result="failed">
<successes>
<target name="target1" />
<target name="target2" />
</successes>
<failures>
<target name="target-name" class="ignored"
message="..." />
<target name="target-name" class="fatal"
message="..." />
</failures>
</summary>
</build-results>

That's just off the top of my head, so it might be completely inappropriate,
but hopefully it gets across the point of having the xml provide useful
information which couldn't happen (so easily) using the trace system you
propose. The meaning of each entry in the log would be much more clear, and
therefore (IMHO) much more useful. Either way, I believe the tasks would
need changing to use a different output mechanism, and we could use that
opportunity to make the output more useful.

(note: obviously we can't necessarily expect to parse the compiler/other
tools output and place it into the relevant <info/>, <warning/> and <error/>
tags, but in these cases we could include the compiler output in an <info/>
tag.)

Thoughts?

Thanks,



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to