Pe 15.12.2013 18:07, "Paul Smith" <psm...@gnu.org> a scris: > > On Sun, 2013-12-15 at 13:38 +0000, 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 and I realise it's > > unfair of me to give you any sort of hard time about it. This feature > > is just a small example of how gnu make will evolve an irregular > > output format that's not easy to change once its "finalised" because > > it's not designed to be extendable. > > I'll quote my comment from the bug report in Savannah: > > > Lastly, and this is where we may need to have more conversation, I'm not so > > excited about adding the formatting capability, at least not this way. I > > think that it could be a very useful thing to allow for specially-formatted > > output from GNU make. For example, perhaps an output format in XML that could > > be easily sucked into tools like Eclipse or whatever for further parsing (I'm > > not a huge fan of XML but it is relatively universal). Now that we have the > > output sync capability it would be straightforward to combine these and format > > the output of recipes for proper XML encoding as well. > > > > But I don't want to add multiple different formatting options, for different > > types of output. I'd prefer to have one comprehensive formatting capability. > > 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. >
Thanks for clarifying this. Could you please confirm if the general direction of the the is OK in the latest patch I sent? > And, I think that this issue is completely separate from profiling and > we shouldn't bundle them. A new output format for make would also mean you'd always need an external tool to analyse the output. I see Tim's point and how it can be useful to be able to inject all sorts of info in the output, but I feel losing the human readability of the output would be a huge loss. Anyway all of this is off topic and a way bigger decision than adding profiling info. What it is in scope and what I would need help with is adding relative time stamp support in the profiling info instead of absolute time stamps. When analyzing the 'simple' output I realised the graphs looked awful because there was such such a scale difference between the time stamp and duration. The absolute time stamp also doesn't fit well worth the scope of the 'simple' output. I tried to pass down a reference time stamp through an environment variable, but I am missing something from the processing since submakes don't see the variable I defined. Help and feedback would be appreciated.
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make