[OpenAFS-devel] Build system tweak required for SUSE

[Marcus Watts]

Jean-Marc Saffroy <saffroy@gmail.com> had replied:
> Date: Mon, 13 Nov 2006 10:21:33 +0100 (CET)
> From: Jean-Marc Saffroy <saffroy@gmail.com>
> To: Marcus Watts <mdw@umich.edu>
> cc: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] Build system tweak required for SUSE 
> 
> On Sun, 12 Nov 2006, Marcus Watts wrote:
> 
> > In fact, the Makefile they do include is not what ships with 2.6,
> > and looks amazingly wimpy...   Oh my.  Wow.  What they ships
> > has these lines in Makefile:
> > 	KERNELSRC    := ../../../linux-2.6.5-7.282
> > 	...
> > 		$(MAKE) -C $(KERNELSRC) O=$(KERNELOUTPUT)
> > which basically means there's a whole another layer of indirection going
> > on here, and the *REAL* kernel source lives somewhere else entirely
> > different (and also means if you don't have *THAT* you can't build modules.)
> 
> This looks a *lot* like what you get when building a vanilla kernel out of 
> its source tree, and there is no real problem with that (except configure 
> does not recognize it as a 2.6 tree, see the small patch I posted a few 
> days ago).

Well, since it's definitely building a vanilla kernel out of its source
tree, the similarity makes a lot of sense.  So, sure, your patch makes
a lot more sense to me now.  I have to admit, I never had occasion to
try building a kernel "out of tree".  The Linux make logic is crazy
enough I honestly wouldn't have expected it to work.  Now I can keep
more kernel builds around.  :-)

> 
> > Mind you, I do have some fairly crazy experimental logic to chase down 
> > kernel build flags in 2.4 by using a variation on the kernel build 
> > process to make it cough up the compiler options being used.
> 
> Did you have to do something special with these flags, or was it just 
> needed for build? Because I think that, back when I was building against 
> 2.4 trees, there was a build method for modules that was very similar to 
> what we have now on 2.6 (and the build flags ended up in a file).

The current distribution openafs build logic for 2.4 makes its own makefile
and uses that without reference to the 2.4 kernel makefile.  That means
it's up to configure to sort out what has to be done to run the compiler
to generate proper load modules.  Here are some of the bits of that logic:
	openafs/acinclude.m4
		might append
			-fomit-frame-pointer
		to LINUX_GCC_KOPTS
	src/cf/linux-test5.m4
		might append one of either
			-march=pentium
		or
			-m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
		and one or more of
			-fno-strict-aliasing
			-fno-strength-reduce
			-fno-common
			-pipe
		to LINUX_GCC_KOPTS
	src/libafs/MakefileProto.LINUX.in
		i386
			-DCPU=586
		amd64
			-mcmodel=kernel -mno-red-zone
		&etc&etc for sparc, alpha, s390, ppc, etc.
Basically, configure is trying to predict what compiler flags
the linux 2.4 Makefile used, which sometimes loses because it's
possible to put weird stuff into .config that changes what
actually was used.

You're right, though, the 2.4 Makefile is capable of building modules
something like 2.6, only not so fancy.  Probably that could be used,
but I elected to take the low road and just steal the options from
the 2.4 build process and plug it into the existing openafs makefile
framework.  So I run it with a makefile "conftest.mk" that that looks
just like this:
	include Makefile
	cflags:; @echo CFLAGS=$(CFLAGS)
	cc:; @echo CC=$(CC)
and use this to suck the options out:
	make -C $KBUILD_SRC -f `pwd`/conftest.dir/conftest.mk KBUILD_SRC=$KBUILD_SRC M=`pwd` V=1 cc cflags
That gets rid of any need to be an oracle and predict what Linux
used, and replaces about 5 trial runs of the compiler with one
run of the kernel make script.

> 
> > The most reliable way I know to determine linux version number
> > is to try building this:
> 
> Yes that's reliable, but if a simpler test is good enough (eg. a certain 
> file or directory exists), it might be nice to save some time (I'm not a 
> fan of configures that take ages to complete, they are CPU- and IO-hungry, 
> and not parallelizable).

Well, you're right.  Looking for the existance of a directory is cheap.
Running the compiler is medium.  Running "Make -C" (AC_TRY_KBUILD26)
to figure out if the "for_each_process" macro is defined is expensive.
The openafs configure logic definitely bogs down when it hits
those tests on linux 2.6.

Instead of using this compiler test to see which kernel I have, I
actually wound up using this compiler test to verify I had correctly
selected the right AC_TRY_KBUILD logic so was going to get good results
for the remaining tests.  It seemed simplier after I kept seeing the
same complaints from people on the mailing list, and then ran into the
identical build problem myself.  For now, this is part of rxk5 and
applies against openafs 1.5.10 or cvs head, though it could certainly
be split out and used separately.  I like your directory patch though
so I'll probably fold that in, especially now that I understand why it's
useful.  Thanks!

...

				-Marcus Watts