I personally think that there should be some sort of message, but it should be modified so that the user does not think it's an error.

Just appending " (yet)" to the error would probably be enough imo.

Thanks.

(It's me from comment #6 again.)

I've just read

http://make.paulandlesley.org/autodep.html

and want to point out that the advanced procedure presented there (building dependency information together with objectes, plus avoiding the error message we discuss here) would not work for the case that the order of object builds matters: It does for Fortran 90, where a module build needs the modules it depends on being built first (with some compilers at least).

So, the automake approach does not make this bug report obsolete (apart from me not liking it doing unnecessary work during rebuilds).

Re: Comment #3:

> All is well. So why the error?

Yes, this is exactly the bug.  The problem is that make generates the error before it realizes that it could rebuild the target.  I've tried on a couple of occassions to fix this by delaying the error message until make is sure there's no way to rebuild the target, but the behavior of make in these areas is complex enough that it's not so simple and my attempts failed.

Re: Comment #4:

> a bona fide bug in include resolution.

No, it's not a bug.  This is expected behavior.  The way GNU make works is it first reads ALL the makefiles, THEN it tries to rebuild ALL the makefiles that don't exist or are not up to date, THEN it re-execs.  It does not rebuild one makefile, re-exec, rebuild the next makefile, re-exec, etc. which is the behavior it would need to have in order for your environment to work properly.

If you want that behavior you can get it: one way is to move the include $(SOMEDIR)/Defs.mk line into Master.mk itself; that way it won't be visible until after Master.mk is built.

If you don't want to do that due to ordering or other issues, you can include a trigger in Master.mk that enables the rest of the includes; for example your top-level makefile could be:

include Master.mk

ifdef SOMEDIR
include $(SOMEDIR)/Defs.mk
endif

ifdef SOME_OTHER_DIR
include $(SOME_OTHER_DIR)/Rules.mk
endif

Just one example:

My makefile includes a dependency-file 'makefile.d' which is automatically created by GCC:

makefile.d : $(SRCS) 
$(CC) -mmcu=$(MCU) -E -MM -I. $(INCFIRST) -I$(INCDIR) $(INCLAST) $^ > makefile.d

include makefile.d

If makefile.d does not exist, make issues an error, then executes the rule and then includes it. All is well. So why the error?

This is a bug that I did report long ago (around 1998)

GNU make just violates the unwritten "golden rule" for all make programs:
 
        If you like to "use" anything, first check whether you have a rule
        that could make the file in question.
 
For makefiles on the Command Line, GNU make follows this rule. If you are in an 
empty directory and call "gmake", GNU make will first try if "Makefile" or 
"makefile" could be retrieved using e.g. "sccs get Makefile" before GNU make 
tries to read the file.
 
For makefiles that appear as argument to an include statement, GNU make ingnores
this rule. GNU make instead, later (too late) executes the rule set and creates 
the missing files using known rules. In order to be able to do anything useful, 
GNU make then executes "exec gmake <old arg list>" after it is done with 
executing the rules. This is complete nonsense.
 
Smake works this way:
 
-       if it is going to "include" a file, it checks whether there is a rule 
        to make the file that is going to be included.
 
-       If the file has been "made", smake includes the file.
 
-       After including the file, smake clears the "has been made already" 
        cache flags for the included file.
 
-       After all make files and all recursive include rules have been made and 
        included, smake checks all rules again. This may result in rare cases 
        that the rule for one of the the include file is executed again.