bugmake - Bugs: bug #102, Make prints an incorrect error for...


bug #102: Make prints an incorrect error for missing includes

Submitter:  Paul D. Smith <psmith>
Submitted:  Sat 20 Apr 2002 08:28:30 PM UTC
Severity:  2 - Minor Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  None Operating System:  Any
Fixed Release:  4.2 Triage Status:  Medium Effort
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sun 10 Apr 2016 12:22:13 AM UTC, comment #10: 

I've fixed this issue: error messages are delayed until make fails to rebuild the makefile, then written.  The fix will be in the next release of GNU make.

Paul D. Smith <psmith>
Group administrator
Thu 24 Dec 2009 05:28:32 PM UTC, comment #9: 

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.


Simon Williams <systemparadox>
Sat 03 Oct 2009 07:25:36 PM UTC, comment #8: 

Added a test for this to the test suite (add -all to see it).

Paul D. Smith <psmith>
Group administrator
Wed 08 Oct 2008 01:03:53 PM UTC, comment #7: 

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

I've just read


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).

Wed 08 Oct 2008 09:41:29 AM UTC, comment #6: 

Do we have an idea to fix this, now?
It is not fatal but really annoying... One workaround may be to make a custom build script that filters the make output displayed to the user, but that's not pretty, eh?

Paul: Is the deferring of the error message still a tricky thing to do?

I really was delighted to discover this automatic include-Makefile generation feature, allowing me nice automatic builds without need for using external tools like automake/conf.
I would even more be delighted to make not complaining without reason. It would help convincing my collegue that this "smart" Makefile I wrote really saves trouble...

Wed 30 Aug 2006 06:21:45 PM UTC, comment #5: 

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

include $(SOMEDIR)/Defs.mk

include $(SOME_OTHER_DIR)/Rules.mk

Paul D. Smith <psmith>
Group administrator
Wed 30 Aug 2006 07:31:00 AM UTC, comment #4: 

This isn't exactly the same thing, but related, and a bona fide bug in include resolution.

Our environment uses one local (as in ./) included makefile that contains, among other things, necessary defintions for finding other included makefiles (that live in the development environment tree, /sw/dev/...). Something like this:

include Master.mk
include $(SOMEDIR)/Defs.mk
include $(SOME_OTHER_DIR)/Rules.mk

where SOMEDIR and SOME_OTHER_DIR are defined in MASTER. When running make with Master.mk checked in RCS, I get the output

Makefile:19: Master.mk: No such file or directory
Makefile:40: /Defs.mk: No such file or directory
Makefile:113: /Rules.mk: No such file or directory
gnumake: * No rule to make target `/Rules.mk'.  Stop.

So in this case make tries to build the target 'Rules.mk' before it has read the makefile 'Master.mk' although 'Master.mk' was included before 'Rules.mk' (and so should be read before it). This clearly violates the golden rule stated by Paul.

Should this be made a separate bug?

Atte Kojo <kojo>
Thu 06 Apr 2006 05:50:31 PM UTC, comment #3: 

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?

Thu 15 Dec 2005 07:37:55 PM UTC, comment #2: 

I absolutely disagree with the algorithm you supply (as used by smake).  That algorithm presupposes that rules to build makefiles are defined before the makefile is included, and that is almost NEVER the case in any make environment I'm familiar with.  In fact, it's quite likely that the rules needed to make makefiles will be themselves contained in an included makefile!

In an environment like this, makefiles can't be built the first time through, and if they are they may well be built using incorrect commands (using some builtin command that will be overridden later).  Make doesn't keep any sort of information about which command was used to build a target, so the second time through make thinks the makefile is up to date even though a completely different command was used to build it!

An even more "golden rule" (and this one is actually written!) for make is that ALL makefiles are fully parsed before ANY targets are built, and GNU make will always obey that rule, even for makefiles.  Anything else absolutely contradicts the "principle of least surprise".

The fix to this bug, when it comes, will be much different: all it will do is defer the generation of the warning for missing include files until AFTER it tries (and fails) to rebuild them.  So, if the makefile is rebuildable you won't see this message.

Paul D. Smith <psmith>
Group administrator
Sat 21 Aug 2004 11:41:04 AM UTC, comment #1: 

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.

Sat 20 Apr 2002 08:28:30 PM UTC, original submission:  

If an "include"'d makefile doesn't exist, GNU make prints an error that it can't be found... even if make knows how to create it and later successfully does so.

Repeat by:

$ cat Makefile
include foo
foo: ; echo foo = bar > $@

$ make
/tmp/1.mk:1: foo: No such file or directory
echo foo = bar > foo

Paul D. Smith <psmith>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by systemparadox (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-10 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.2
        Triage StatusVerified Medium Effort
    2009-10-03 psmith Triage StatusNone Verified

    Back to the top

    Powered by Savane 3.12