Update of bug #102 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Fixed Release:
Follow-up Comment #9, bug #102 (project make):
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.
Update of bug #102 (project make):
Triage Status:None => Verified
___
Follow-up Comment #8:
Added a test for this to the test suite (add -all to see it).
_
Follow-up Comment #7, bug #102 (project make):
(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
w
Follow-up Comment #6, bug #102 (project make):
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 messag
Follow-up Comment #5, bug #102 (project make):
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
Follow-up Comment #4, bug #102 (project make):
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
Follow-up Comment #3, bug #102 (project make):
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 mak
