On 15 December 2013 16:07, Paul Smith wrote:
> In other words, I prefer to take a page from Git, GDB, and other
> projects where the default output is human readable but probably not
> easily parsed by tools, and then provide a different output format
> option that provides machine-parse-able for
On Sun, 2013-12-15 at 13:38 +, Tim Murphy wrote:
> I suppose I'm skirting around saying that I think gnu make needs an
> output format in the same way that valgrind has "--xml=yes". I'm not
> an XML fan really - JSON might be an alternative.
> It isn't your problem to provide such a mechanism
Sorry you asked for an example.
Here's an overall one from the Symbian Raptor build system that uses a
shell wrapper to implement a structured output format:
Unfortunately I don't have the right toolchain installed hence the error.
Note the time flag.This was used in a very large build
Sorry for the side-track but for future reference when discussing the
hypothetical rigorous output format:
On Sun, Dec 15, 2013 at 5:38 AM, Tim Murphy wrote:
> I'm not an XML fan really
Agree.
> JSON might be an alternative.
IMHO, YAML is to JSON what JSON is to XML (oh, and vim > emacs!).
Da
I suppose I'm skirting around saying that I think gnu make needs an
output format in the same way that valgrind has "--xml=yes". I'm not
an XML fan really - JSON might be an alternative.
It isn't your problem to provide such a mechanism and I realise it's
unfair of me to give you any sort of hard
Pe 29.11.2013 12:30, "Tim Murphy" a scris:
>
> When I did something similar (which I am not allowed to post) I made a
> new file for each submake and the output filename "base" was in an
> environment variable. I realise that nobody ever wants to change the
Does it make sense to separate the pro