paul@mecazh.uu.ch (Paul Breslaw) (10/02/90)
Instead of all this political GNU/HP bashing, would anyone mind if
I went back to the original subject of this discussion, namely GNUmake,
and could someone help me with the following observation.
Here is a Makefile
OBJ = foo.o
all: $(OBJ)
@echo $(OBJ) up to date
foo.o: foo.h foo.c
cc -o foo.o $<
Now
$ gnumake -n
cc -o foo.o foo.h <== observe
echo foo.o up to date
$ /bin/make -n
cc -o foo.o foo.c <== observe
echo foo.o up to date
The GNUmake documentation defines $< as the name of the *first* dependency.
The HPmake documentation says it is evaluated only for inference rules
(or the .DEFAULT) rule. (Hence the meaningless symbolic target 'all'.
Without it $< doesn't get evaluated at all, and I get cc -o foo.o as output)
Can someone explain why so simple a Makefile is treated so differently
by the two make's. And, if the question is not meaningless, which is
correct?
Paul Breslaw
--
Paul Breslaw, Mecasoft SA, | telephone : 41 1 362 2040
Guggachstrasse 10, CH-8057 Zurich, | e-mail : paul@mecazh.uu.ch
Switzerland. | mcsun!chx400!mecazh!paulpaul@mecazh.uu.ch (Paul Breslaw) (10/02/90)
I wrote >>Another plague to avoid is CFLAGS = -O. Use CFLAGS = +O1 after you have >>checked that the program goes. The -O option only exists so the folks >>at HP can make slow core dumps :-) mjs@hpfcso.HP.COM (Marc Sabatella) writes: >I'm sorry you feel that way. We do our best to fix all bugs that are reported >against the optimizer. There are very few in 7.0 on the Series 300. We can't >fix them if people avoid using the optimizer rather than submit bug reports, >though. Reporting bugs with code optimizers is not something that the average *user* of a compiler is going to find easy. This is all the more true if the bugs occur while compiling code *which he did not write*, for example when building PD software. If I am trying to build, let us say Perl, on an HP machine, and the only reason it doesn't work is because the optimiser is broken and I haven't a clue which bit of code it has mis-optimised, are you seriously telling me that I should 1. First of all convince myself that there is nothing wrong with the 26764 lines of C code that Larry Wall wrote. 2. Report to HP that I think there is something wrong with their compiler because somewhere within the enclosed 26764 lines of C, the compiler breaks. I learned the hard way that perl (pl#18) and xdvi failed simply because of the compiler option -O. There were other examples but I cannot now remember what they were. I use +O1 by default and I will continue to do so with PD software. Sometimes I use -O with my own software but only after I am convinced that it works. Some months ago during the last -O discussion on this group, I wrote that a broken optimiser is less than useless. It is a veritable plague. That is still true. If you have bugs in your optimiser, please don't ask me to find them. Paul Breslaw -- Paul Breslaw, Mecasoft SA, | telephone : 41 1 362 2040 Guggachstrasse 10, CH-8057 Zurich, | e-mail : paul@mecazh.uu.ch Switzerland. | mcsun!chx400!mecazh!paul