[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Make bug?!?
Re: Make bug?!?
Wed, 02 Apr 2003 10:09:51 +0200
Thanks for your reply. After a little more experimenting, bearing your remarks
in mind, I discovered that my tcsh was causing my troubles. The option
"set correct = all" in combination with the line "@$(CC) $(CFLAGS) -M
$(C_FILES) | sed '/^[^ ]*:/s/^/'$(ODIR)'\//' >> $(DEPENDENCIES)" in my
makefile was responsible for the bad make results. After either removing
this line from my makefile or setting "correct" to something else than
"all", make was running like a charm.
Conclusion: it is NOT a make bug, but some tcsh magic in combination with
But it still makes me wonder how this could happen... If anyone has an
explanation for it, please let me know.
Thanks again for the quick and helpfull reponse.
At 04:59 PM 4/1/03, you wrote:
%% Nathan Huizinga <address@hidden> writes:
nh> I'm experiencing some strange behaviour from GNU make version 3.80.
nh> running on a Gentoo/Linux machine with tcsh as my default shell.
nh> When running "make", everything build just fine.
nh> But when running "make clean", it spits out the following message:
nh> `cat -s GNUmakefile Makefile makefile |& sed -n -e "/No such
nh> "/^[^ #].*:/s/:.*//p"`: No match.
nh> and stops building the given target.
Note that make does not use either your shell (tcsh) nor bash to run
scripts. It always uses /bin/sh (unless you reset the SHELL variable
inside your makefile).
On a Linux box it's often the case that /bin/sh is bash, but not
always. You might check that (I'm not familiar with Gentoo Linux).
nh> When running the same two commands in a bash shell, it works as
nh> I also discovered that "gmake" is a symbolic link to "make" and
nh> gives me the correct behaviour when I run "gmake clean" in my tcsh
nh> So my question is: "What's the difference between 'make' and
nh> 'gmake'?", because "gmake" is 'only' a symbolic link to "make"?!?
There is none. make does not look at its name and change its behavior.
nh> Another opservation is that this behaviour is NOT present in GNU
nh> make 3.79.1.
You are going to have to provide a sample makefile that exhibits this
problem. Probably just the clean target is enough. Please don't send
thousands of lines of makefile: reproduce the problem with the smallest
example you can and send that along with the commands you executed and
the output you received.
Paul D. Smith <address@hidden> Find some GNU make tips at:
"Please remain calm...I may be mad, but I am a professional." --Mad