[OpenAFS] Latest docs on building the OpenAFS source code

[Simon Wilkinson]

On 1 Oct 2010, at 18:07, David Boyes wrote:

>> Yeah, sorry.  :/  We're not using Autoconf properly in a lot of ways.
>> We're closer than we were, but the configure and build machinery =
still
>> needs a lot of cleanup.
>=20
> I need to do some work in this area as well. Is there a set of =
requirements, or at least a rough set of expectations as to what a =
rational build process should do for OpenAFS, ie, what sort of packages =
does it need to build, platforms, etc?=20

What follows is from a Unix perspective. In addition to this, we =
obviously 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 =
diverged so dramatically across all of the supported platforms that we =
now have a multitude of different options to support...

*) Transarc or normal paths
*) Install or dest
*) libafs.ko or openafs.ko

...

Despite our best efforts, I would anticipate howls of anger if we were =
to kill off any of these. So the build system has to be able to support =
being many things to many people.

Secondly, we build our source multiple times in many different ways ...

*) 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)

The upshot of all of this is that if I add a new object file to AFS, I =
potentially have to modify 5 different Makefiles (6 if you count =
Windows). This is obviously prone to developer error.

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.

Thirdly, we now have a very complicated set of feature probes to deal =
with different platform capabilities. Many of these are pretty standard, =
but we do a lot of complex things to ensure that we can build on many, =
many, different Linux kernels.

Those are from the developer/packagers perspective. =46rom the user's =
perspective 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 should 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.

> How much restructuring of the build process is tolerable? The current =
one is pretty messy, and really difficult to automate/test in any easy =
way. Would it be feasible to scrap the accumulated cruft and fit it into =
a more modern build framework like cmake?

The main problem with moving to a different tool is that most of us =
understand autoconf and make. cmake adds an entire new layer of =
unfamiliarity, and in that respect is probably likely to be regarded =
with suspicion. Personally, I would rather see us improve the current =
system within the limitations of autoconf, make (and possibly automake), =
rather than throwing it all away to start again.

Cheers,

Simon.