[1590] in Kerberos-V5-bugs
Re: Patches to Beta 5-1/2 (24 July snapshot)
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Aug 8 15:23:51 1995
Date: Tue, 8 Aug 1995 15:23:37 -0400
From: Theodore Ts'o <tytso@MIT.EDU>
To: Derek Atkins <Derek.Atkins@Eng.Sun.COM>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: Derek Atkins's message of Mon, 7 Aug 1995 16:59:59 -0700,
<9508072359.AA00533@squeamish-ossifrage.Eng.Sun.COM>
Date: Mon, 7 Aug 1995 16:59:59 -0700
From: Derek Atkins <Derek.Atkins@Eng.Sun.COM>
Yea, this was the point. And you're right, I probably should have
used a goto in this instance. I even considered it when I was making
the change, but for some reason the "never use goto" training took
over.
Not to worry, I rewrote your patch to use the "goto cleanup" paradigm
which is used in most of the other kerberos library routines.
Mmm.. Perhaps I should have included more explanation. If you'd like
me to re-submit the patches with explanations, I can do that. Many of
the patches are, IMHO, self-explanatory, such as the addition of
$(SHELL) to commands, etc.
No, that's fine. At this point I've figured out and applied all the
patches except for the autoconf changes (have you contacted djm yet, or
shall I do that) and the Makefile dependency changes.
To play devil's advocate, how is make supposed to know what
source-file to look for. It could be a .c file, a .s file, a .f file;
it could be a .y file that needs to be compiled to a .c file and then
to a .o file... I don't consider this a bug in make. I believe that
you should include an explicit dependency on all the source files.
And yes, SunSoft make does fail in the cases where such a dependency
does not exist.
make is supposed to be able to figure this out on its own. In the case
where it may come from a .c, .f, or .s extension, all other makes can
figure this out on their own; they basically look and see which of these
files exist. What the search order that a particular make might use
isn't well defined, but if there is only one possible source file which
could be used to make the .o, it's generally safe to assume that the
make program can figure this out on its own.
It is true that in the foo.y -> foo.c -> foo.o case, some makes don't
get this right, and so it's not protable to assume that all make
programs can handle a double rule like this. In general, you need to
put in at least one dependency rule so that it can figure out the chain.
The reason why I hestitate in adding all of these extra dependencies is
that I am intending to add automatically generated dependency rules to
the Makefile.in files sooner or later, and so I've kept manually
inserted dependency rules down to an absolute minimum, using them only
when they're absolutely necessary.
- Ted
