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

[Eddy Petrișor]

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" <address@hidden> a scris:
>
>
> 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.