Date: Tue, 17 Jan 1995 15:42:01 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: krbdev@MIT.EDU
FYI.....
My reply will follow cc'ed to this address.
- Ted
------- Forwarded Message
To: tytso@MIT.EDU, gnu@cygnus.com
Cc: eichin@cygnus.com, jmr@cygnus.com
Subject: K5: Slashes don't separate file components any more!
Date: Sun, 15 Jan 1995 22:15:00 -0800
From: John Gilmore <gnu@cygnus.com>
The standard include file name for K5 can't be "krb5/krb5.h",
because on the Mac, slash is just another file character. They use ':'
for the file component separator. (Our K4 makefiles use some one-char
Makefile macros for handling this, and all source files avoid
file paths unless they come from a system-dependent config file.)
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
I picked k5-*.h as an internal naming convention because all the names
will also (for PC) have to be unique within 8.3 chars. This gives us
5 chars of uniqueness to play with.
Initially, krb5.h will contain everything, but we'll start moving
stuff into k5-int.h as soon as we identify things that we know
SHOULDN'T be in the API. My suggestion is that k5-int.h #include
"krb5.h" so that all its callers don't have to.
We'll also have to fix references to all the other krb5/*.h include
files. Some may need new names (e.g. krb5/dbm.h => k5dbm.h since
otherwise it conflicts with the system dbm.h). We'll need to figure
out which are "internal" and which are "external", since external ones
will need clearly identifiable (as Kerberos) names, while internal
ones can have more haphazard names.
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.
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).
I'll be at Usenix starting on Tuesday. I'll be reading mail there,
and will probably get some Kerb work done from there too.
John
------- End Forwarded Message
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
To: "Theodore Ts'o" <tytso@MIT.EDU>
Cc: John Gilmore <gnu@cygnus.com>, eichin@cygnus.com, jmr@cygnus.com,
krbdev@MIT.EDU
In-Reply-To: Your message of "Tue, 17 Jan 1995 16:06:00 +0500."
<9501172106.AA21978@dcl.MIT.EDU>
Date: Wed, 18 Jan 1995 11:30:10 -0800
From: John Gilmore <gnu@cygnus.com>
> 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.
This sounds like a good process. You know the tree and the API a lot
better than I -- do you want to make the first proposal?
John