[2475] in Kerberos_V5_Development
Re: Make depend what is it supposed to/should do?
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Thu Jul 31 20:15:00 1997
Date: Thu, 31 Jul 1997 20:14:24 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ezra Peisach <epeisach@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Ezra Peisach's message of Thu, 31 Jul 1997 12:46:51 -0400,
<9707311646.AA30670@kangaroo.mit.edu>
The general design of "make depend" is that we don't want to force
random people on the net who want to compile Kerberos 5 to have to do
yet another recursive ("make depend") pass over the tree. It takes too
long to compile Kerberos V5 as it is!
So the basic theory behind the current system is that "make depend" is
only done by MIT developers; that the "make depend" modifies the
Makefile.in, and it strips out OS-dependent header files (since we
assume the OS header files are unlikely to be changing; and if they
have, you should just do a make clean); that since developers only do
this when they know they've made a fundamental change, the "make depend"
shouldn't recursively descend, because that might not be the right
thing.
So, that explains why "make depend" does what it currently does:
>Currently, make depend does not recurse into subdirs.
>Currently, make depend assumes that you are in a build tree which has all the
> generated include files made.
>Currently, make depend modifies the $(srcdir)/Makefile.in file
>Currently, make depend assumes that one is using a native compiler (or
> /mit/cygnus) to remove the OS specific include information.
In other words, it's not an accident; its behaviour was carefully
designed.
I'm willing to entertain arguments that there's a better way to do
things; but note that we had some very good reasons for architecting
things the we have them now....
- Ted
