[1387] in Kerberos_V5_Development
Re: build system redesign ideas
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Jul 15 12:32:40 1996
Date: Mon, 15 Jul 1996 12:32:29 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: "E. Jay Berkenbilt" <qjb@netrail.net>
Cc: tlyu@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: [1382]
I pretty much agree completely with Jay (hi, Jay!). Here is what I
consider as the really important points:
o A build system based on gmake with the "expand" feature, using
autoconf to determine OS variables, contains all the best features of
every other option anyone is proposing. The Makefiles are amazingly
short, simple to understand, and simple to maintain. No
pre-compilation step is required, so the system is fast. autoconf can
be used for configuration, to make the system portable. All of the
actual "make" (dependency and build) functionality is written in a
single language, which is essentially the same as standard make, which
therefore the largest number of people are likely to understand. The
expand feature provides parameterization in a clean, easy to
understand, and extremely flexible way.
o gmake is more portable than Kerberos; I am under the impression that
gmake exists on Windows and Mac (correct me if I'm wrong). Therefore,
anyone that can use Kerberos can use gmake. It is illogical to assume
that someone who is going to obtain Kerberos over the net, build it,
and install it is incapable of also building gmake, which is a vastly
simpler application, particularly given that we can provide the
sources ourselves.
o The "expand" patches to gmake are minor and apply cleanly to the
newest version, 3.74. Roland McGrath told me that no new version of
gmake is coming in the forseeable future, so the patches are likely to
work fine for a long time. If there ever is a new version of gmake,
there is good reason to believe the expand patches will be in it.
o The current build system does not meet its goal of working with
vendor makes, anyway. It uses VPATH, and has other problems with
broken vendor makes on some platforms. Thus, gmake or some other
non-broken make is required on many platforms anyway.
I assert the rewriting yet another configure-based build system to use
vendor makes is a waste of time and resources that would be better
spent implementing a gmake+expand+configure build system. I volunteer
to work on a gmake build system.
Barry