At 12:03 1/3/01 +1100, Conor MacNeill wrote: >> It is not X has always been done this way thus we should do it. The >> arguement is "Changing an accepted standard breaks a lot of environments >> with little or no advantage". >> > >Your argument is that we should NOT provide additional information (the >task producing a particular piece of output) because that affects the >ability of some editors to parse the output.
some editors ? All editors that provide this functionality would be closer to it ;) >That information is an >advantage to me. It helps me know which task is failing. How do you find >that out? The question is how useful is that in general? How often can you not tell where the error is coming from? What proportion of error messages are directly attributable to "compiling" compared to other build file errors? I put it to you that compiling errors are the most common form of error. Following the 80/20 rule you make it easy to work with these errors. Making it easier means following the standard ... >Why do I have to lose that information? Who saids you have to loose it ? You can still enable it via another switch ;) I wasn't actually going to bring this issue up to 2.0 though but somehow the issue up and pounced ;) How about we keep it as is in 1.x for backwards compatability but maybe ant2.0 defaults to the standard? Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
