jimm@amiga.UUCP (Jim Mackraz) (02/10/89)
Dear friends,
Thank you for the many kind letters explaining that LMK will
indeed recompile a touched .c file.
I'd like to change my description of my problems with LMK to
the following:
"While I am very fond of the Lattice 5.0 development environment
and am certain that LMK is a useful tool for many programmers,
I find that it is insufficiently compatible with the make
programs to which I am accustomed, and am therefore looking
for alternatives."
Here's an example makefile that it can't handle. The several big
problems I've had are all relating to the include dependency line.
If I remove it, I think I can use LMK in the interim. (Note that
I'm working on some projects considerably more complicated than
hello.c ;^)
I've reported all problems and their support is extremely responsive,
but I don't anticipate a fix to this problem soon.
jimm
# lattice development test makefile
LC1FLAGS=-iINCLUDE: -d
.c.o:
lc1 $(LC1FLAGS) -oquad:$*.q $*
go quad:$*.q
lc2 -o$*.o quad:$*.q
.o.lst:
omd >$*.lst $*.o $*.c
LIBS=lib:lc.lib
OBJS=hello.o foo.o
hello: $(OBJS)
blink FROM lib:c.o $(OBJS) LIB $(LIBS) TO $@
hello.lst: hello.o
# this is what confuses LMK, keeping it from updating hello.o when
# hello.c is changed. Also, if you touch foo.c, it recompiles hello.c.
# I had this line once when foo.o was created from foo.asm.
# In that case, I think it tried to compile hello.asm when foo.asm
# was touched.
#
# I reported this behavior and the response was that contrary
# to my assertion, this was not the standard way of making
# dependencies on include files.
foo.o hello.o: hello.h
--
Jim Mackraz, I and I Computing "Like you said when we crawled down
{cbmvax,well,oliveb}!amiga!jimm from the trees: We're in transition."
- Gang of Four
Opinions are my own. Comments are not to be taken as Commodore official policy.phil@titan.rice.edu (William LeFebvre) (02/11/89)
In article <3324@amiga.UUCP> jimm@amiga.UUCP (Jim Mackraz) writes: >Dear friends, >... ># this is what confuses LMK, keeping it from updating hello.o when ># hello.c is changed. Also, if you touch foo.c, it recompiles hello.c. ># I had this line once when foo.o was created from foo.asm. ># In that case, I think it tried to compile hello.asm when foo.asm ># was touched. ># ># I reported this behavior and the response was that contrary ># to my assertion, this was not the standard way of making ># dependencies on include files. > >foo.o hello.o: hello.h #define HEAVY_SARCASM Oh wow. Well, someone had better tell that guy who wrote the paper "Make - a Program for Maintaining Computer Programs". You know, that paper that gets distributed with some versions of Unix? The author put in a example using an include file called "defs", and he sure used the dependency "y.o: y.c defs". He even went further that that: he defined a whole set of object files and used the dependency "$(OBJECTS): defs". Guess that's all wrong, then, since that isn't "the standard way of making dependencies on include files". After all, what does Stu Feldman (the author of that paper) know about "make"? #undef HEAVY_SARCASM William LeFebvre Department of Computer Science Rice University <phil@Rice.edu> #define FOOTNOTE For those that don't catch the sarcasm, Stu Feldman wrote the very first "make" for Unix. Many Unix implementations still use that program, or some derivative of it, for "make". He was also, by the way, severely chastised by his cohorts for using a name that contained as many as four letters. Apparently, everyone else wanted just 2 or 3 letters. #undef FOOTNOTE