Re: [bug #40639] GNU Make with profiling information

[Eddy Petrișor]

Pe 15.12.2013 18:07, "Paul Smith" <address@hidden> 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.