[OpenAFS] Latest docs on building the OpenAFS source code

[David Boyes]

> I don't think we've ever really done any kind of requirements capture
> in this area.=20

OK. Here's some thoughts I had:

Should:

Run on Linux, Solaris, AIX, Irix for certain; others?
Generate build configurations for native tools to build;=20
Allow overrides for common tools
Desirable to also generate Windows Visual Studio build configurations
Must permit option specification and provide sane defaults.
Should support native packaging options (RPM, DEB, pkgadd/IPS, AIX, Irix) a=
s well as leaving the binaries in a directory with 'make install' to do the=
 deed

Basic build logic:

1) Determine platform and build environment, and create header file with th=
e local details
2) Build common parts like libraries (build the variations as separate targ=
ets, based on the interrogation in 1)
3) Build server components if desired (part of interrogation)
4) Build cache manager components if desired
5) Build userspace components if desired
6) Execute tests (if available)
7) Build packages (if desired)

The comment above about driving native tooling is kind of interesting in th=
at you'd be able to start managing the source in the way you want (eg, sayi=
ng here are a list of components separate from dealing with the actual make=
 files themselves, and let the tool generate the make files for the appropr=
iate platforms). At least that's how cmake does it. You would end up with s=
omething like this for the build process on all platforms:

0) put source tree somewhere
1) mkdir /someconvenientdir-for-binaries
2) cd /someconvenientdir-for-binaries
3) cmake <sourcetree>
4) make
5) make test
6) make install (optional)=20
7) make package

The same method works on Windows, except it can also generate VS workspaces=
.=20

> 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.=20

Isn't that the case with any build tool other than the status quo, however?

I'm not married to cmake; it just struck me as one reasonably successful to=
ol that manages a code base of comparable complexity for lots of platforms =
(KDE uses it). I don't know if anyone is using it to build kernel modules, =
but a little experimentation is probably in order.=20

> 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.

At some point the current build system will collapse of its own complexity.=
 I'd like to ask the question of what else could we use before we reach tha=
t point.=20