[1822] in Kerberos_V5_Development
Re: make vs. gmake and the Athena source tree
daemon@ATHENA.MIT.EDU (Tom Yu)
Sun Sep 29 22:56:13 1996
Date: Sun, 29 Sep 1996 22:56:04 -0400
To: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
Cc: Greg Hudson <ghudson@MIT.EDU>, krbdev@MIT.EDU
From: Tom Yu <tlyu@MIT.EDU>
In-Reply-To: <199609300223.CAA01131@orchard.medford.ma.us>
>>>>> "Bill" == Bill Sommerfeld <sommerfeld@orchard.medford.ma.us> writes:
>> If all four lists are right next to each other in a Makefile,
>> it's unlikely that they will get out of sync.
Bill> Yes, but if there's only one list, it's *impossible* for it
Bill> to get out of sync.
The problem is some .o files are compiled from .c files that are
generated via other means (e.g. compile_et). This raises a number of
questions, e.g. should OBJS include only .o files built from .c files
that are human-generated? Should SRCS include generated .c files?
These points make it somewhat more difficult to simply say
OBJS=$(SRCS:.c=.o) and be done with it.
Certainly one approach is
OBJS = all .o files
CSRCS = all .c files
GENSRCS = all generated .c files
SRCS = all non-generated .c files, .et files, etc.
And then we can have something like
OBJS=$(CSRCS:.c=.o) $(GENSRCS:.c=.o)
So do we want to require a make that does suffix substitutions? I'm
kinda neutral on this subject myself...
---Tom
