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

 
 

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

Submitted by:  Paul D. Smith <psmith>
Submitted on:  Sat 20 Apr 2002 08:28:30 PM UTC  
 
Severity: 2 - MinorItem Group: Bug
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Component Version: NoneOperating System: Any
Fixed Release: NoneTriage Status: Verified

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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.

Thanks.

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>
Project Administrator
Wed 08 Oct 2008 01:03:53 PM UTC, comment #7:

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

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

Anonymous
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

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

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

Paul D. Smith <psmith>
Project 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?

Anonymous
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>
Project 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.

Anonymous
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:

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

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

Paul D. Smith <psmith>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 03 Oct 2009 07:25:36 PM UTCpsmithTriage StatusNone=>Verified

    Back to the top


    Powered by Savane 3.1-cleanup