[OpenAFS] Latest docs on building the OpenAFS source code

[Derrick Brashear]

On Oct 1, 2010, at 2:46 PM, David Boyes <dboyes@sinenomine.net> wrote:

>> I don't think we've ever really done any kind of requirements capture
>> in this area.=20
>=20
> OK. Here's some thoughts I had:
>=20
> Should:
>=20
> Run on Linux, Solaris, AIX, Irix for certain; others?

Linux Solaris MacOS AIX would be the 4 I'd pick in that order if just 4. The=
n BSDs, then Irix, then HPUX

> 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 d=
eed
>=20
> Basic build logic:
>=20
> 1) Determine platform and build environment, and create header file with t=
he local details
> 2) Build common parts like libraries (build the variations as separate tar=
gets, 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)
>=20
> The comment above about driving native tooling is kind of interesting in t=
hat 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 f=
iles themselves, and let the tool generate the make files for the appropriat=
e platforms). At least that's how cmake does it. You would end up with somet=
hing like this for the build process on all platforms:
>=20
> 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
>=20
> The same method works on Windows, except it can also generate VS workspace=
s.=20
>=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
>=20
> Isn't that the case with any build tool other than the status quo, however=
?
>=20
> I'm not married to cmake; it just struck me as one reasonably successful t=
ool 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, bu=
t a little experimentation is probably in order.=20
>=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.
>=20
> 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=20

it's gotten simpler recently and further simplification seems in near-term g=
rasp.=