On 15 December 2013 16:07, Paul Smith <psm...@gnu.org> 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 formats. I'm not interested in > trying to create one output format that solves both of those problems.
The way I have seen this addressed before is to have a filters that render the comprehensive output into human-readable forms of varying kinds. e.g. if you like the Linux kernel-style where your output is only "CC file.o" unless there's an error, then a filter can be made that produces this. If you prefer gnu makes' standard output then that would be the default. If you want coloration or to produce output as HTML then those are also possible. For various reasons the filters we used had to parse the "structured output" into readable form but if you were designing such a thing into make then you could do it without a print-then-parse. It's fairly key for recipes to be able to inject information into this output e.g. attribute=value pairs so that logical information about the build can be passed into the log or on towards reporting tools. e.g. the name of the team to which a particular target belongs or whether it is an intermediate, internal or releasable file. Even more interesting would be an indexing filter which would generate a table that allowed one to jump directly to the point in a log where some file was mentioned or where some error occurred. When builds get really big this would be nice as even grep can be overwhelmed by something large enough. I have gone off-topic. I apologise. Regards, Tim -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
