[1326] in Kerberos_V5_Development
Re: sub-packages of krb5 for autoconf purposes
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Jun 17 12:08:58 1996
Date: Mon, 17 Jun 1996 12:08:42 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: raeburn@cygnus.com
Cc: tlyu@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <tx1g27x1xia.fsf@cygnus.com> (message from Ken Raeburn on 14 Jun 1996 21:50:37 -0700)
Following a conversation with Ted and Tom about this on Friday, here
are my thoughts on the autoconf changes.
1. The current build system is too slow and complicated; anything
that can make it simpler should be seriously considered. In
particular, not having a configure.in in every directory would be a
good thing.
2. There is an issue of how each Makefile.in learns its BUILD_TOP
value, the relative path to the top of the build tree. I understand
that the reason there is a currently a configure.in in every directory
is so that this can be computed at configure time. I also understand
that there is a plan to modify autoconf to provide this information so
that a configure.in is *not* required in every directory. I think
both of these plans are wrong. Each Makefile.in should just have
hard-coded into it the relative path of the top of the Kerberos tree.
This is the vastly simpler solution. It is not like the source tree
is reorganized that often, and if it is reorganized only one line per
Makefile.in needs to be changed---that's a lot fewer lines of code and
programmer time that creating and maintain a more "automated" system.
3. I do not think we should invest any significant resources into
making pieces of the Kerberos tree seperable. IMHO, the job of the
Kerberos team is to create and maintain Kerberos. It is not our job
to create and distribute a generic telnet (for example). Sure,
someday someone MIGHT want to use the Kerberos telnet without
Kerberos, and MAYBE we will have the time and resources to support
that configuration. In reality, no, we will never have the time or
resources, and if we did they would be better spent making Kerberos
smaller and easier to use. Adding false generality and real
complexity to an already messy system in the name of a possible use at
an unknown future time is absurd.
Who me, opinionated? Nah. :-)
Barry
