[823] in Kerberos_V5_Development
[John Gilmore: K5: Slashes don't separate file components any more!]
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Jan 17 15:42:11 1995
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
