[1394] in Kerberos_V5_Development
Re: ADDENDUM: Re: build system redesign ideas
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Mon Jul 15 14:46:41 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: qjb@netrail.net, tlyu@MIT.EDU, krbdev@MIT.EDU, tytso@MIT.EDU
Date: Mon, 15 Jul 1996 14:46:11 EDT
From: Marc Horowitz <marc@MIT.EDU>
>> Using non-standard tools for building for Windows and Mac --- and gmake
>> is nonstandard for those platforms --- is a complete non-starter.
>>
>> Why? Technical reasons, or political/ideaological ones (ie: Windows
>> users won't demean themselves by touching unix tools)?
Biological reasons. Most windows programmers' brains are too small to
comprehend anything but the native gui.
That said, if there is a way to make the native build environments
consume gmake in a clever way, I'd be all for it. This would give the
kerberos team one consistent build system to work with, while allowing
windows and mac programmers to continue using their native build
environments. I'd even be willing to forgo the OV enhancements as a
compromise position.
>> Does autoconf/configure count as a native compilation tool, or are we
>> not using it on Windows?
The MIT tree uses something called wconfig, which is a tool which
pretends to be configure on a windows box. If you want to know what
it does, ask Ted, but don't go swimming for one hour afterwards.
wconfig is certainly not a native tool, but it is "hidden" from the
programmer unless he goes and looks for it. I think we could do the
same thing for gmake, and gmake is a much more commonly understood
tool than wconfig.
Marc
