[OpenAFS-devel] Changes to the build system

[Simon Wilkinson]

As was mentioned here earlier, a patch of mine that reworks and =
rationalises the OpenAFS build system was recently committed to master. =
This patch has pretty far ranging implications for how Makefile rules =
for OpenAFS are written, so I thought it might be worth publicising it =
here.

The initial impetus for the patch was to solve Phil Moore's problem of =
not being able to override CFLAGS and LDFLAGS, but it turned into a =
pretty wide ranging rationalisation of our build system.

The first rule of build club is that you should never override any of =
the 'user' variables - CC, LDFLAGS, or CFLAGS. These are for the user to =
modify configure's settings. Instead, alternative variables have been =
provided to customise the build system on a per directory basis ...

OpenAFS has three different build types on Unix - LWP, pthread and =
shared-library. The build system now provides the following variables:

LWP_CFLAGS      PTH_CFLAGS      SHD_CFLAGS
LWP_LDFLAGS     PTH_LDFLAGS     SHD_LDFLAGS

These can be used to create rules which are specific to a particular =
build type. However, our normal model
is to have an entire directory build with a particular build type. In =
this case, you should include either

src/config/Makefile.lwp
src/config/Makefile.pthread
src/config/Makefile.shared

in your Makefile. Each of these files define an AFS_CCRULE and =
AFS_LDRULE which can be simply used to build
a target. For example:

bar.o: foo.c
	$(AFS_CCRULE) foo.c
baz.o: baz.c
	$(AFS_CCRULE) baz.c
bar: bar.o baz.o
	$(AFS_LDRULE) bar.o

The first thing to note here is that you don't have to specify the =
target - that's automatically derived from the build rule. We don't =
automatically derive the source, because we can't do that in a portable =
manner that also permits dependencies to be specified. The use of $? is =
discouraged for this reason.

The second thing is that you don't have to supply anything beyond the =
build rule. All of the standard compiler options are embedded within the =
CCRULE.

The third thing is that all of these headers have a .c.o suffix rule. =
So, the 'baz.o' target above is actually unnecessary, and the same =
results can be obtained with:

bar.o: foo.c
	$(AFS_CCRULE) foo.c
bar: bar.o baz.o
	$(AFS_LDRULE) bar.o baz.o

CFLAGS can be overriden on a per target basis by setting the =
CFLAGS_<object> variable. For example, to build baz.o with -DFUBAR, you =
can simply do ...

CFLAGS_baz.o =3D -DFUBAR
bar.o: foo.c
	$(AFS_CCRULE) foo.c
bar: bar.o baz.o
	$(AFS_LDRULE) bar.o baz.o

The mechanism for disabling warnings-as-errors for a particular file =
then becomes:
CFLAGS_bar.o =3D @CFLAGS_NOERROR@

If you wish to override CFLAGS for a whole module, simply set =
MODULE_CFLAGS in your Makefile

And that's pretty much it. I suspect that more refinement will come over =
the coming weeks ...

Comments? Brickbats?

S.