[824] in Kerberos_V5_Development
Re: K5: Slashes don't separate file components any more!
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Jan 17 16:06:20 1995
Date: Tue, 17 Jan 1995 16:06:00 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: John Gilmore <gnu@cygnus.com>
Cc: gnu@cygnus.com, eichin@cygnus.com, jmr@cygnus.com
Cc: krbdev@MIT.EDU
In-Reply-To: John Gilmore's message of Sun, 15 Jan 1995 22:15:00 -0800,
<199501160615.WAA19600@cygnus.com>
Date: Sun, 15 Jan 1995 22:15:00 -0800
From: John Gilmore <gnu@cygnus.com>
To make the K5 tree portable to the Mac, we'll have to pick another
name for the krb5 include file. My suggestion:
krb5.h -- defns used by application programs (the API)
k5-int.h -- defns used internally to Kerberos itself
Well, it sounds like the main thing that needs to happen is that all of
the files in src/include/krb5 need to be moved to src/include.
Unfortuantely, since there area *lot* file flies in src/include/krb5,
and some of the names conflict with system include files, we should move
towards folding more things into krb5.h.
At one point you had talked about trying to merge all or most of the
publically needed files into krb5.h, so that a binary distribution would
consist of a single library and a single .h file. Are you still
suggesting such an approach? If so, there are a number of include files
which are built as part of the configuration file, namely config.h and
the com_err error table files, which we're going to have to deal with
somehow. If you want to deal with trying to deal with a way that
automatically builds the krb5.h file, that's fine with me (it's going to
probably over 100k, though!).
Making this change will also require passing proper -I options during
the build, so that e.g. #include "krb5.h", by itself, is good enough
for the compiler. We may want to separate the include files into a
directory of external ones (which get installed with the library
binaries) and internal ones (which don't) rather than the current
structure based on which subcomponent of Kerberos they come from.
This will limit the number of -I options we have to pass in every
compile.
We're already passing -I options through to the build; as I said, I
think this is mostly an issue of moving things to top-level include
directory.
Most of the .h files in include/krb5 are ones that are required to be
known by files in the entire krb5 distributions. .h files which only
need to be used by one directory are mostly already located in the
appropriate subcomponent directory.
When and how would you like this change to be made? I could just
start whacking, but without fundamental agreement on which direction
to go, I could waste a lot of effort (and/or end up with a tree with
thousands of changed files, which lasts for weeks and is harder and
harder to merge other peoples' massive changes into).
Argh, another vast change that's going to do inflict major trauma to the
source tree....
The hardest part of merging all of these changes in will be in the
include files themselves. Changing where krb5.h is going to be found
will affect hundreds of files, but those changes will be easy to merge
in.
So, here's my proposal --- we quickly reach agreement on which include
files we actually want to be exposed, and we rename them quickly, and/or
hack the Makefiles to generate the global src/include/krb5.h by
concatenating appropriate .h files from src/include/krb5/*.h.
At that point you can go whacking lots of files at your convenience, and
checking them in as you go. Because the old include files are still in
include/krb5, we can keep the tree stable and compiling while you make
the changeover. That way, we can continue doing work while you convert
over the files (although hopefully the conversion should take all that
long anyway.)
What do you think?
- Ted
