[Top][All Lists]

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

Re: [bug #33138] .PARLLELSYNC enhancement with patch

From: Tim Murphy
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Tue, 16 Apr 2013 15:31:48 +0100


I tried it out. It all works as I imagined - you were perfectly clear:

bash-4.2$ ./make -Otarget -j 5 -f test.mk
start a
end a
start b
end b
start c
end c
start d
end d

So this is great and you can see that there are 4 targets in my makefile and that each one is a "start X" followed by an "end X".  I don't see any enter/exit delimitation - have I missed out some option?

My question is: how does the human eye work out what's going on in the log above? It's probably because there is a pattern and you can just see it.  What If I had output like this:

cp x y
gcc y -o z
cp z foo

Is that 3 rules, 2 rules or 1?  What I'd like to be able to do is demarcate them.

startrule: z
cp x y
gcc y -o z
startrule foo
cp z foo

Now it doesn't take an intimate knowledge of the build or any human-level intelligence to work out which things belong together.

How about this:

startrule: z modulename: the_z_module
Error: unsafe memory accesses detected - tell the developer!
endrule: exitcode: 2

Now in a build I can quickly see which module the error belonged to and presumably I can look up who to send the bug report to.

I might want other things:

startrule: z time: 0.0000001
endrule: z time: 0.02000001

Now I can see where the time is going in my build - how long various tasks take. I can put it into graphs and so on.

I chose "startrule" and "endrule" arbitrarily and the kinds of things people might want to put there are limitless so it would be best if it could be configurable somehow.  The cheapest and simplest version of this that I can think of is to be able to expand variables at the start and end of the output

I might set:

START_RULE_OUTPUT=startrule: $@ $(timestamp)
END_RULE_OUTPUT=endrule $@ $(timestamp)

Then I'd use my plugin skills to write a $(timestamp) function.



On 16 April 2013 13:43, Paul Smith <address@hidden> wrote:
On Tue, 2013-04-16 at 09:57 +0100, Tim Murphy wrote:
> When most rules are a single job this doesn't seem important but when
> you're doing anything non trivial it becomes hard to see what is
> where.

Just to be clear: in this implementation the output from all individual
commands in a recipe are collected and printed at once.  It's not
actually a per-job thing, but rather a per-target thing.

Don't know if that helps at all (I think it's better this way).

You could help some brave and decent people to have access to uncensored news by making a donation at:


reply via email to

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