[1395] in Kerberos_V5_Development
Re: ADDENDUM: Re: build system redesign ideas
daemon@ATHENA.MIT.EDU (E. Jay Berkenbilt)
Mon Jul 15 14:51:29 1996
Date: Mon, 15 Jul 1996 14:42:40 -0400
From: "E. Jay Berkenbilt" <qjb@netrail.net>
To: tytso@MIT.EDU
Cc: bjaspan@MIT.EDU, bjaspan@MIT.EDU, tlyu@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <9607151720.AA23467@dcl.MIT.EDU> (tytso@MIT.EDU)
Ted writes:
> Using non-standard tools for building for Windows and Mac --- and gmake
> is nonstandard for those platforms --- is a complete non-starter. We
> *must* using native build tools. Cygnus tried using Cyg-win 32 to build
> Krb5, and they've figured out this was a mistake.
>
> We want non-Unix programmers to start using Kerberos V5, then we can't
> use Unix-based tools. As much as we can, we have to use the native
> based compilation tools.
Although I agree with Barry and myself (I don't always agree with my
self, BWT) on the issue of gmake being more portable than kerberos and
of the idea of using gmake on non-UNIX systems to NOT be a
non-starter, I will point out that, in may instances, the use of tools
such as autoconf is not as necessary (though perhaps not completely
unnecessary). Consider emacs 19 and non-UNIX platforms as an example.
Building it is a hybrid of using UNIX tools in a non-UNIX environment
and using prefabricated configuration files. Though not 100% true in
all cases, the statements that "Windows is Windows" or "Mac is Mac"
are much more true than "UNIX is UNIX".
In other words, I think it would be a huge mistake to lose out the
opportunity to use a relatively powerful and pleasant-to-use build
system that works seamlessly on a UNIX platform because it doesn't
work perfectly (or at all, though I doubt that to be the case) on a
non-UNIX system? Using the least common denominator may not be the
Right Thing in this case. (Consider the example of using prototypes.
You don't not use prototypes just because some systems don't support
them. Instead, you either use preprocessor tricks to allow to use
prototypes, or you use a tool like ansi2knr to remove them at build
time.)
This said, there are several options. One is to determine why using a
build system based on UNIX-based tools on a non-UNIX system doesn't
work. Not just politcally why, but practically and technologically
why. If the reasons can be easily overcome, they should be overcome.
If not, then it is quite likely that having more than one build system
would be better than having one build system that is inadequate. If
you are very concerned about not duplicating information (which I
usually am), then you can devise a system that will allow you to
generate the makefiles, etc., for the various build systems from a
common source. This generation process can be done at the time of
assembling the distribution (like building configure scripts with
autoconf) so that the end user doesn't have to have the capability to
do this task on their own. That means you can use Perl, or whatever
to do that. The result should hopefully be that, as you are doing
your day-to-day development, you have a comfortable and highly
functional build system (with automatic dependencies, etc.), and that
other people, when they grab the kerberos distribution off the net,
have something that they can configure and build easily, preferably
without having to wait through a configuration generation step that
takes almost as long as the build itself.
I realize that this is easier said than done, but I think it's still
easier than trying to invent from the ground up a functional and
widely portable build system based on vendor-supplied tools.
Marc writes:
> Jay, do you build for non-unix systems? How do you handle this?
Well, uh, actually, not really too much. I have built for a lot of
non-UNIX systems, but always with UNIX-based cross compilers.
(Generally this is for real-time operating systems or embedded
processors). In my new life in a PC-based environment, I am doing
most of my development under Linux, but those who are doing builds are
using either fully integrated environments like Visual C++ or are
using commercial DOS/Windows-based tools that are themselves based on
UNIX make. I don't have a lot of experience building anything of
non-trivial size native on a non-UNIX environment, though. I wonder
what Atria and Pure Software use to compile Clear Case and Purify for
Windows NT.
--
E. Jay Berkenbilt (qjb@netrail.net) | Member, League for Programming Freedom
| lpf@uunet.uu.net, http://www.lpf.org
