Paul, I would really appreciate feedback on this. If the problem is the licensing, don't worry about my rights, I will gladly give them to the FSF.
Pe 18.12.2013 13:28, "Eddy Petrișor" <eddy.petri...@gmail.com> a scris: > > > 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
