[OpenAFS] Latest docs on building the OpenAFS source code

[Derrick Brashear]

I mostly agree with this; however, a few nits and comments.


>> I need to do some work in this area as well. Is there a set of requireme=
nts, or at least a rough set of expectations as to what a rational build pr=
ocess should do for OpenAFS, ie, what sort of packages does it need to buil=
d, platforms, etc?
>
> What follows is from a Unix perspective. In addition to this, we obviousl=
y have a completely separate Windows build process.
>
> I don't think we've ever really done any kind of requirements capture in =
this area. One of the problems is that the way that we build OpenAFS has di=
verged so dramatically across all of the supported platforms that we now ha=
ve a multitude of different options to support...
>
> *) Transarc or normal paths
> *) Install or dest
> *) libafs.ko or openafs.ko

libafs.ko versus openafs.ko isn't that big of a deal compared to the
rest. but yes.

> *) For the kernel module
> *) For the userspace cache manager
> *) For the java cache manager
> *) Twice for the Apache plugin (this isn't currently built, and probably =
no longer builds, but the rules are there)
> *) For LWP libraries
> *) For pthread static libraries
> *) For pthread shared libraries (with -fPIC)

LWP will be dying obviously. pthread versus pthread-PIC could be
handled today with make rules. the java cache manager *should* become
a special case of the userspace cache manager. this is other work and
in truth is probably a better use of time than rewriting the make
system first.


> Ideally I'd like to have a single location that records, for example, RX =
objects which I can simply add an object to and have it build correctly for=
 all of those build types. I did have a cunning plan for doing this within =
the existing system, but haven't yet had the time.

Well, it's better and worse. You only want some subset of those things
in each case; I'd rather that be coded per-module with ifdefs than per
(class of) makefile. Then it's obvious why I don't have function X in
the kernel: the source makes it obvious. And you have one list of
files built for things where it might matter: "all of them". Some just
happen to provide nothing.


> Those are from the developer/packagers perspective. From the user's persp=
ective the problem is that we look like a standard autoconf package. People=
 expect these to work in a particular way, and we currently don't. So, we s=
hould work on taking CC (we do, on Linux) CFLAGS, CPPFLAGS, LDFLAGS and so =
on on the command line, and doing the right thing with them. The fact that =
we don't is largely to do with the complexity of the build system necessary=
 to support all the different targets listed above.

We never can, in some sense, unless we force people to build as root
or have 2 sets of behavior, one if root, one if not. Make install
should install a kernel module, right? Well, ...
>
>> How much restructuring of the build process is tolerable? The current on=
e is pretty messy, and really difficult to automate/test in any easy way. W=
ould it be feasible to scrap the accumulated cruft and fit it into a more m=
odern build framework like cmake?
>
> The main problem with moving to a different tool is that most of us under=
stand autoconf and make. cmake adds an entire new layer of unfamiliarity, a=
nd in that respect is probably likely to be regarded with suspicion. Person=
ally, I would rather see us improve the current system within the limitatio=
ns of autoconf, make (and possibly automake), rather than throwing it all a=
way to start again.

does cmake buy us anything if we're assuming builders (as opposed to
developers) don't have it installed? never mind suspicion: if we can
do it without screwing people who are building and it improves their
lives, we should examine it. forcing another dependency to be able to
build, on the other hand, is probably a poor choice.