kbuild: Various updates for 2.6.8

Hi Linus.

I have arranged with Andrew that he sucks my kbuild tree in -mm, and this is the fist update I send direct to you.

The following set of patches has been in -mm for a few days now with no complaints. Please include these before 2.6.8.

bk pull bk://linux-sam.bkbits.net/kbuild

The most important fix is the $LANG fix. Without this users from .cz, .fr etc. cannot use menuconfig/xconfig with good result.

The cset's:
o kbuild: Introduce source symlink in /lib/modules/.../
o kbuild: Create Makefile in output directory if != kernel tree
o drivers: move STANDALONE to drivers/base/Kconfig
o kbuild: Two simple kbuild patches
o kbuild: Fix up moving of modpost
o kbuild: Move modpost files to a new subdir scripts/mod
o kbuild: scripts/genksyms/parse.c_shipped needs to be rebuilt
o kbuild: Less intrusive LANG override, fixes menuconfig
o kbuild: Rebuild .spec file when kernel version changes
o kbuild: Allow make O=<obj> {cscope,tags} to work
o kbuild: build binary rpm from pre-built tree

Full descriptions below.
Regular diffs available at http://linux-sam.bkbits.net:8080/kbuild

Sam

[email protected], 2004-07-28 00:36:33+02:00, [email protected]
kbuild: Introduce source symlink in /lib/modules/.../

Traditionally when building a kernel the source and the output files are mixed.

When building a kernel using the O= syntax to save output files in a separate directory a way is needed to locate the kernel source.
The implemented solution is a new symlink 'source' being added to /lib/modules/.../
used to locate source for an installed kernel. The original symlink build points to the directory containing the output files.

Please note that when the kernel is build with source and output files mixed the two symlinks 'build' and 'source' will point to the same directory, thus no changes compared to before.

Two options was considered:
a) Adding a new symlink pointing to the output files "object"
=> All external modules have to specify O= to build
=> External modules grepping in .config or .h files
in include/asm needs to be updated
=> External modules that do grep in source code and
ordinary header files just works

b) Let the build symlink point to the output files and introduce a new symlink "source" pointing to the kernel source
=> External module can be build without specifying O= => External modules grepping in .config or .h files
in include/asm just works
=> External modules that do grep in source code and
ordinary header files needs to be updated

Based on the above option b) is considered the least painfull alternative.

So to sum up:
- If a distro does not use separate output dir => no change
- If a distro uses separate output dir =>
- Trivial external module just builds
- Non-trivial (build-wise) external modules are probarly broken

Without this patch
- If a distro does not use separate output dir => no change
- If a distro uses separate output dir =>
- Trivial external modules had to specify O= to build, and the directory being pointed at was not obvious
- grep in .config or include files in asm/ required knowledge where to locate output files

Preferred syntax for building external modules are the following:

make -C /lib/modules/uname -r/build M=pwd

[Substituting 'M=...' with 'SUBDIRS=... modules' give same effect].

When the kernel is built using separate output directory the above invocation of make will invoke the generated Makefile located in the output directory - that again will invoke the Makefile located in the kernel source tree root.

Patch includes contributions from:
Andreas Gruenbacher <[email protected]>

[email protected], 2004-07-27 23:54:53+02:00, [email protected]
kbuild: Create Makefile in output directory if != kernel tree

When building a kernel using the O= syntax to save output
files in a separate output directory now create a small Makefile in that same dir.
This Makefile allow one to use make in the output directory without the hassle of going back to the kernel source tree.
The O= option is added by this Makefile stub.
Please note that the Makefile silently overwrite an old one, so changes will be lost if modified.
If there is a need to tweak a Makefile in the output directory it is recommended to use the filename 'makefile', which GNU Make will try first.

[email protected], 2004-07-27 23:44:01+02:00, [email protected]
drivers: move STANDALONE to drivers/base/Kconfig

Move STANDALONE from init/Kconfig to drivers/base/Kconfig . This way, it's besides PREVENT_FIRMWARE_BUILD.

[email protected], 2004-07-23 01:29:55+02:00, [email protected]
kbuild: Two simple kbuild patches

foo1.patch: spelling correction in Makefile
foo2.patch: replace SUBDIRS with M in Documentation/kbuild/modules.txt

From: Kornilios Kourtis <[email protected]>

[email protected], 2004-07-23 01:28:19+02:00, [email protected]
kbuild: Fix up moving of modpost

A few small issues to fix the moving of modpost.
A few files was missing in the commit and one change needed. Also bk ignored the files in their new location.

[email protected], 2004-07-23 00:59:36+02:00, [email protected]
kbuild: Move modpost files to a new subdir scripts/mod

Move modpost and support files to scripts/mod.
Directory named mod by Sam.

From: Brian Gerst <[email protected]>

[email protected], 2004-07-23 00:39:37+02:00, [email protected]
kbuild: scripts/genksyms/parse.c_shipped needs to be rebuilt

parse.c_shipped has never been regenerated after parse.y has been modified 4 months ago.

[email protected], 2004-07-23 00:32:23+02:00, [email protected]
kbuild: Less intrusive LANG override, fixes menuconfig

The locale override caused problems for some people with locale setiings different from 'C'. make menuconfig was looking bad / unuseable.
This patch limit the override of locales to the part where we actually descend the kernel doing the full build of the kernel.
The speed improvement is the same.

make menuconfig should now be useable for all locale settings again. Thanks to Marcel Sebek <[email protected]> for pointing out this problem and being paitent in testing.

[email protected], 2004-07-21 00:14:47+02:00, [email protected]
kbuild: Rebuild .spec file when kernel version changes

Make a dependency in scripts/package/Makefile to top-level Makefile forcing .spec file to be generated when kernel version changes.

[email protected], 2004-07-21 00:03:20+02:00, [email protected]
kbuild: Allow make O=<obj> {cscope,tags} to work

Allow make O=<obj> {cscope,tags} to work

[email protected], 2004-07-20 23:57:07+02:00, [email protected]
kbuild: build binary rpm from pre-built tree

Many times it would be nice to quickly package up a kernel tree you're working on, without having to rebuild the whole thing again from a clean source tree (like the current rpm-pkg target does). The patch below adds an "binrpm-pkg" target which uses your existing (already built) tree.
Modified by me to always do a make and use binrpm-pkg.

By any chance could you update make rpm so it respects the -j flags? Single-threaded make rpm is horrifically slow.

I'm using the patch below at the moment, but am not very particular as to the form of the solution.

-- wli

Index: sched-2.6.8-rc2-mm1/scripts/package/mkspec
===================================================================
@@ -57,14 +57,14 @@
 echo "%build"
 
 if ! $PREBUILT; then
-echo "make clean && make"
+echo "make clean && make %{_smp_mflags}"
 echo ""
 fi
 
 echo "%install"
 echo 'mkdir -p $RPM_BUILD_ROOT/boot $RPM_BUILD_ROOT/lib $RPM_BUILD_ROOT/lib/modules'
 
-echo 'INSTALL_MOD_PATH=$RPM_BUILD_ROOT make modules_install'
+echo 'INSTALL_MOD_PATH=$RPM_BUILD_ROOT make %{_smp_mflags} modules_install'
 echo 'cp $KBUILD_IMAGE $RPM_BUILD_ROOT'"/boot/vmlinuz-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"
 
 echo 'cp System.map $RPM_BUILD_ROOT'"/boot/System.map-$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"

I have below patch queue up already but will try to experiment with a better fix. Something where we pass all options to make.

I have to redo some of the package stuff anyway cause today there needs to be too much arch dependent knowledge spread out in several files. But for now klibc is on top of the list, the package stuff will wait a bit.

Sam

This will work fine for me.

Thanks.

-- wli