Hi, 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 endrule: startrule foo cp z foo endrule: 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. Regards, Tim On 16 April 2013 13:43, Paul Smith <psm...@gnu.org> 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: http://www.thezimbabwean.co.uk/friends/
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
