[1400] in Kerberos_V5_Development
Re: ADDENDUM: Re: build system redesign ideas
daemon@ATHENA.MIT.EDU (tytso@MIT.EDU)
Tue Jul 16 12:15:17 1996
Date: Tue, 16 Jul 1996 09:14:48 -0700
To: eichin@MIT.EDU
Cc: bjaspan@MIT.EDU, qjb@netrail.net, tlyu@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <xe1g26t44gt.fsf@maneki-neko.cygnus.com> (message from Mark
Eichin on 15 Jul 1996 17:00:18 -0400)
From: tytso@MIT.EDU
The real problem with using non-native tools is that it makes it that
much less likely that programmers *outside* of the core Kerberos
unix-weanie developers will adopt Kerberos V5. Have you ever had to
deal with people like Steve Dorner at Qualcomm, trying to get him to
integrate Kerberos or Hesiod into his Eudora product? Have you seen the
fragmentation in the Kerberos V4 Mactinosh arena, primarily because Mac
developers refused to deal with various Unixisms in the Kerberos V4
base?
Some Unixisms are absolutely necessary, because a common source code
base is critical. However, I don't want to gratuitously add more
Unixisms if there isn't a good reason.
As far as the accusation that we require gmake already because we use
VPATH, that's simply not true. Users don't have to compile with VPATH,
and if they don't use VPATH, the existing make system will build using
most Makes. SGI make's is a notable example, but that's because it's
broken beyond all belief.
- Ted
