[1512] in Kerberos-V5-bugs
comments about use of autoconf
daemon@ATHENA.MIT.EDU (E. Jay Berkenbilt)
Wed Jul 5 10:48:48 1995
Date: Wed, 5 Jul 1995 10:43:49 -0400
From: "E. Jay Berkenbilt" <ejb@ERA.COM>
To: krb5-bugs@MIT.EDU
Hello. First, I'd like to say that I'm very impressed with the use of
autoconf in kerberos 5. I think this makes all the difference in the
world in terms of configuration, and I think autoconf was generally
used well with good use of local macros and keeping garbage out of
configure.in, etc. I do have one comment, however: have autoconf
generate a header file rather than a bunch of -DSYM=val strings for
the makefiles. I suggest calling the file krb5-autoconf.h or
krb5/autoconf.h (or something in keeping with whatever file naming
conventions are in place for portability reasons) but not calling it
something like config.h that will conflict with other things. This
file should be installed. The reason for this is that this will allow
installed kerberos header files to reference autoconf definitions
without their having to be built in the context of the kerberos source
tree. (Right now, for example, you install krb5/ext-proto.h, and that
file references autoconf values.)
Hmm. I just noticed krb5/k5-config.h. Perhaps my suggestion should
instead be that this be used more uniformly and that ext-proto.h
either include it or not be installed.
BTW, I have sent several comments or small patches to
krb5-bugs@mit.edu, and have not gotten any response at all. Are my
messages being received? If you're busy and don't have time to
respond to all messages, that's fine; I don't need a response for
everything. However, I would like to know that my messages are being
received. Also, if they're being trashed, I won't bother to take the
time to provide feedback from my testing. When I sent in bug reports
for gcc, emacs, or other GNU software, I always get responses even if
they say, "Thanks for your report. We've added this to the bug list
but don't expect to fix it for a long time."
--
E. Jay Berkenbilt (ejb@ERA.COM) | Member, League for Programming Freedom
Engineering Research Associates | lpf@uunet.uu.net, http://www.lpf.org
