Re: fatal errors for missing include files.

[Ian Dunbar]

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