Hi Paul,
Thanks for the explanation. I am now satisfied you are telling the truth :)
Not really. The times where it makes any difference are very few, and the performance penalty that would be incurred to re-invoke make after each makefile was recreated could be quite large.
I checked this out. Using my example still, the cost (excluding updating of .mk files) is:
N = # of makefiles = 3 (Makefile, sub.mk, subsub.mk)
Case #1 where no .mk files already exist: Cost = N invokations of make + N(N+1)/2 reads of individual makefiles
Case #2 where .mk files exist but are out of date: Cost = 2 invokations of make + 2*N reads of individual makefiles
Case #3 where .mk files exist and are up to date: Cost = 1 invokations of make + N reads of individual makefiles
Does it seem ok to you? I can show how I calculated that if you like, but I am going to assume I am correct for the moment.
Now lets look at the cost if the system was changed to update the file before looking at what it includes. I think this first one is basically how you expect it would behave:
Solution #1:
Read Makefile update sub.mk Restart Read Makefile Read sub.mk update subsub.mk Restart Read Makefile Read sub.mk Read subsub.mk
Cost = N invokations of make + (at least) N(N+1)/2 reads of individual makefiles
(and possibly more, if you read included files before updating them, and generate non-fatal errors)
So you are quite correct, this is more expensive (or at best equal to the current worst cast), and I wouldn't be willing to change to it either (just for the sake of correctness :-)
However, is there some (non-implementation) reason that it can't proceed like this?:
Solution #2:
Read Makefile update sub.mk Read sub.mk update subsub.mk Read subsub.mk
Cost = 1 invocation of make + N reads of individual files
I can accept of course that that kind of solution may well not be at all easy or even possible within the current implementation of make.
By the way, I can give another (perhaps minor) justification for changing the current way. Unlike previously, in this one make does at least know how to generate subsub.mk, but still fails.
If I introduce a syntax error into subsub.mk, and update subsub.prj to correct that error, make fails fatally, even though it knows subsub.mk is out of date, has a rule to make it, and the error is corrected in the .prj file.
Makefile:1: Reading Makefile sub.mk:1: Reading sub.prj/sub.mk subsub.mk:1: *** missing separator. Stop.
This can't be worked around by the empty target. I have to do "rm subsub.mk".
I can believe that this kind of generating .mk files from some other type of project file is not typical, or perhaps recommended usage of make, but equally, I am sure that I am not the only person who does it either. It's not that esoteric surely?
But, anyway, I guess even if it's actually possible there is not likely to be such a change anytime soon, since it's clearly non-trivial.
Heh. You don't believe me? :).
Well, I just couldn't square what you were saying with what appeared to be happening. The empty target, and looking at the warnings explains that though. Make is far too subtle :)
Best regards, Ian
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
_______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make