Pe 11.01.2014 20:58, Paul Smith psm...@gnu.org a scris:
Sorry, I've been mostly away from my systems recently.
On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote:
Thanks for clarifying this. Could you please confirm if the general
direction of the the is OK in the latest patch I
On Tue, 2014-01-14 at 11:58 +0200, Eddy Petrișor wrote:
I understand the interest in the amount of time a given job takes to
run, but I guess I don't understand the need for a start time
offset
at all. Isn't it sufficient to record the start time of a job, then
when it's complete show
2014/1/12 Paul Smith psm...@gnu.org:
On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote:
Could you please confirm if the general direction of the the is OK in
the latest patch I sent?
Conceptually it seems OK. I'm still not jazzed about having any more
than one output format, and I'd
To some, using a spreadsheet might not seem like the most worthwhile
way to visualise timing information.
If it was me, I'd be far more concerned about whether I could write a
script that could easily cope with all this information. Builds with
hundreds of thousands of targets were common for me
I forgot to say that start times don't need to be absolute times -
only relative to the start of the top level gmake if possible. That
creates a problem for submakes I suppose.
I would guess that one could put the absolute build start time in an
environment variable like MAKE_START_TIME and
2014/1/14 Tim Murphy tnmur...@gmail.com
To some, using a spreadsheet might not seem like the most worthwhile
way to visualise timing information.
That's why I thought it can be useful to provide the information in
various formats.
I found useful the graphs provided via a graph from data in
Sorry, I've been mostly away from my systems recently.
On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote:
Thanks for clarifying this. Could you please confirm if the general
direction of the the is OK in the latest patch I sent?
I will take a look.
What it is in scope and what I would
It's nice to know when in the build a job was scheduled. e.g I have a
huge job that gets scheduled at the end of the build - wouldn't it be
nicer if it was scheduled at the beginning? Perhaps I can redesign my
makefile to achieve that if I know.
On 11 January 2014 18:58, Paul Smith
On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote:
Could you please confirm if the general direction of the the is OK in
the latest patch I sent?
Conceptually it seems OK. I'm still not jazzed about having any more
than one output format, and I'd prefer that format to be in a
more-or-less
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,
Pe 15.12.2013 18:07, Paul Smith psm...@gnu.org a scris:
On Sun, 2013-12-15 at 13:38 +, 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
Pe 29.11.2013 12:30, Tim Murphy tnmur...@gmail.com a scris:
When I did something similar (which I am not allowed to post) I made a
new file for each submake and the output filename base was in an
environment variable. I realise that nobody ever wants to change the
Does it make sense to
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
Sorry for the side-track but for future reference when discussing the
hypothetical rigorous output format:
On Sun, Dec 15, 2013 at 5:38 AM, Tim Murphy tnmur...@gmail.com wrote:
I'm not an XML fan really
Agree.
JSON might be an alternative.
IMHO, YAML is to JSON what JSON is to XML (oh, and
Sorry you asked for an example.
Here's an overall one from the Symbian Raptor build system that uses a
shell wrapper to implement a structured output format:
recipe name='tools2linkexe'
target='/home/tim/epocroot/epoc32/release/tools2/linux-i386-libc2_17/rel/tool_exe'
host='tsuro'
layer=''
On Sun, 2013-12-15 at 13:38 +, 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
On 15 December 2013 16:07, Paul Smith psm...@gnu.org wrote:
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
Follow-up Comment #6, bug #40639 (project make):
Here is a new version of the patch.
Author: Eddy Petrișor eddy.petri...@gmail.com
Date: Tue Nov 19 05:14:40 2013 +0200
Now can choose profile format from predefined options
Define 4 hard-coded profile printing formats which can
Additional Item Attachment, bug #40639 (project make):
File name: profile-predefs-ga4937bc8.patch Size:9 KB
___
Reply to this item at:
http://savannah.gnu.org/bugs/?40639
___
Message sent
Follow-up Comment #7, bug #40639 (project make):
Please check https://savannah.gnu.org/bugs/download.php?file_id=29801 instead
of file #29800
___
Reply to this item at:
http://savannah.gnu.org/bugs/?40639
When I did something similar (which I am not allowed to post) I made a
new file for each submake and the output filename base was in an
environment variable. I realise that nobody ever wants to change the
way they implemented something but I thought I'd mention it.
Also, having written a few
FWIW
As for profiling output, this should probably go to a file (possibly
with a .PID on the end) , not stdout .unless. you start to
embrace the idea of structured output for everything that make
produces.
I have used XML before and it has advantages, not the least of which
is that it is
Pe 25.11.2013 11:09, Reinier Post reinp...@win.tue.nl a scris:
Can't this functionality be provided by a wrapper $SHELL?
Sure, it's an extra exec(),
but it will keep the make code base simpler.
I'm not sure if I understand what you mean. Do you mean wrapping all
target invokes in a
On Wed Nov 20 22:47:20 2013, eddy.petri...@gmail.com (Eddy Petrișor) wrote:
On Tue Nov 19 22:29:22 2013, Reinier Post wrote:
Follow-up Comment #1, bug #40639 (project make):
I have created a cleaned up rebased branch that contains only changes for
the
profiling feature so it can be
Follow-up Comment #3, bug #40639 (project make):
I rebased the patch on top of f5f5adb6, updated to use O and OS macros, and
strlist type for the -P/--profile/--profile-format option parameter.
The patch is attached.
(file #29698)
___
Follow-up Comment #4, bug #40639 (project make):
Hi Eddy; thanks for your interest in improving GNU make! I think the idea of
providing more statistics for builds is very interesting. While I agree it
could be done externally (for example, by setting the SHELL variable to a
command that would
26 matches
Mail list logo
