Issue 66651 - Potential speed up possibility for mkdepend
Summary: Potential speed up possibility for mkdepend
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: solenv (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: hjs
QA Contact: issues@tools
URL:
Keywords:
: 66652 (view as issue list)
Depends on:
Blocks:
 
Reported: 2006-06-22 15:33 UTC by jens-heiner.rechtien
Modified: 2013-08-07 15:34 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
prototype for batched mkdepend call (7.46 KB, patch)
2006-07-03 16:34 UTC, hjs
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description jens-heiner.rechtien 2006-06-22 15:33:24 UTC
Currently we call mkdpend once for each file to be compiled. The mkdepend
documentation suggests that it might be worthwhile to call mkdepend for all
files in one makefile at once.

==== snippet from mkdepend.man ====

     The approach used in this program enables it to run an order
     of  magnitude faster than any other "dependency generator" I
     have ever seen.  Central to this performance are two assump-
     tions:  that all files compiled by a single makefile will be
     compiled with roughly the same -I and -D options;  and  that
     most  files  in  a single directory will include largely the
     same files.

     Given these assumptions, makedepend  expects  to  be  called
     once for each makefile, with all source files that are main-
     tained by the makefile appearing on the  command  line.   It
     parses  each source and include file exactly once, maintain-
     ing an internal symbol table for each.  Thus, the first file
     on the command line will take an amount of time proportional
     to the amount of time that a normal  C  preprocessor  takes.
     But  on  subsequent files, if it encounter's an include file
     that it has already parsed, it does not parse it again.

==== end snippet from mkdepend.man ====
Comment 1 jens-heiner.rechtien 2006-06-23 10:51:22 UTC
*** Issue 66652 has been marked as a duplicate of this issue. ***
Comment 2 hjs 2006-07-03 16:34:05 UTC
Created attachment 37469 [details]
prototype for batched mkdepend call
Comment 3 hjs 2006-07-19 15:57:44 UTC
@vq: if you look at the rule with the single echo, it might be handy to have
some kind of "nop" command: command handled internally like "echo" but without
any output... is this possible?
Comment 4 quetschke 2006-07-19 17:41:05 UTC
I didn't check, but do you know when target conditionals are evaluated? See
CONDITIONAL MACROS in the dmake man page. That might work.

If that fails I could convince dmake's runargv() command to skip the execution
of commands if they start with a comment. That would mean the recipe line
would still be created but not executed. Something like this:

all : ; \#$(assign all_local_slo+:=$<)

would trigger the assign but the execution would be inhibited.

Or instead of the coment sign we could just invent a "virtual" nop command, only
known to dmake, any suggestions for the name? __eval__ ?

I have another one ;) Michael proposed that once, we could teach dmake to use
its own (to be implemented) echo command whenever it is not executed in a shell
(intentionally or forced by SHELLMETA because of variables/redirecting/etc.)
Comment 5 quetschke 2006-07-19 17:46:14 UTC
The conditional macro could work, I just tried:

--- makefile.mk ---
SHELL*:=/bin/sh 
SHELLFLAGS*:=-ce

all : ; @echo all

all ?= dummy := $(shell +date > qqq)
--- makefile.mk ---

$ dmake.exe -rf makefile.mk
all

... and it creates a qqq file that contains the current date.
Comment 6 quetschke 2006-07-19 22:31:04 UTC
Alas, it seems we cannot use conditional macros for this purpose. From the man
page:

                    ... Activation [means setting the macro] occurrs after all
       inference, and .SETDIR directives have been processed and after  $@  is
       assigned,  but  before  prerequisites are processed; thereby making the
       values of conditional macro definitions available  during  construction
       of prerequisites.

I checked that $< and $? are not set when evaluating the macro :(
Comment 7 quetschke 2006-07-19 23:48:54 UTC
Ok, this works for me:

--- makefile.mk ---
SHELL*:=/bin/sh 
SHELLFLAGS*:=-ce

al% : ; $(not $(assign ALLDEP=$@))

doit : all
	@+echo "ALLDEP: $(ALLDEP)"
--- makefile.mk ---

$(nil ..) does not work, see issue 67585, but as assign returns the macro name
$(not ..) works as well. This relies on the (undocumented) feature that empty
recipe lines are not executed.
Comment 8 hjs 2006-07-20 11:57:18 UTC
evaluating commented out lines looks somhow dirty to me ;)

isn't the internal echo used already in these cases? i still remember the crash
on "echo $(some_empty_var)"  which vanished when prtepending "+"

i tried $(nil ...) and didn't notice that it was the nil that didn't work. i'll
play with $(not ... )

Comment 9 hjs 2006-08-23 11:39:07 UTC
implemented in CWS ause060
Comment 10 quetschke 2006-10-12 22:50:07 UTC
Tricky implementation ;) Looks good to me.
Comment 11 hjs 2006-11-06 16:26:30 UTC
.