[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eddy Petrișor
Subject: Re: [bug #40639] GNU Make with profiling information
Date: Wed, 18 Dec 2013 13:28:40 +0200

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]