[Top][All Lists]

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

Re: fatal errors for missing include files.

From: Ian Dunbar
Subject: Re: fatal errors for missing include files.
Date: Wed, 01 Sep 2004 04:58:07 +0000

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
   Read Makefile
   Read sub.mk
   update subsub.mk
   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,

Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

reply via email to

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