-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
The kernel build project is proud to announce the first general release
of kernel build for kernel 2.5 (kbuild 2.5).
http://sourceforge.net/projects/kbuild/, Package kbuild-2.5, download
release 1.
This is a complete redesign and rewrite of the kernel build system.
Although it is primarily intended for the 2.5 kernel series, it can be
used on 2.4 kernels, in fact it was developed under 2.4. Only a few
kbuild 2.4 files are changed by this patch and the changes are such
that you can still do a kbuild 2.4 compile, even with the kbuild 2.5
patch installed.
Features of kbuild 2.5. For a fuller description, get the patch and
read Documentation/kbuild/kbuild-2.5.txt.
Supports separate source and object directories. You can compile
multiple versions of the kernel from a single source tree, using a
separate object directory and config for each version. You can even
compile different architectures simultaneously from the same source
tree.
Supports a common source and object directory. The default mode is
the same as kbuild 2.4, to use the same tree for both source and
object. Even in this mode, kbuild 2.5 treats almost all the source
files as read only, no more time stamp fiddling with .h files. The
exceptions are files that are generated at run time and are
incorrectly being shipped as part of the kernel tar ball. I will be
sending patches to remove these files from the 2.4 tar ball.
Obviously you can only compile one kernel at a time in this mode.
Supports multiple source directories. As the development of the
kernel has become more distributed, it has become harder for external
developers to package their code so it compiles against the correct
kernel tree and with the correct options. With multiple source tree
support (shadow trees), external code can be treated as if it were
part of the base kernel tree. This is useful for developing new
drivers, new file systems, testing replacements for existing drivers,
overlaying architecture specific patches on the base kernel etc.
One global Makefile for the entire kernel. Instead of make
recursively decending through every directory in the source tree,
kbuild 2.5 collects the makefile fragments from all directories,
verifies them and merges them into a single global makefile. When
make is given the whole picture, it can do a much better job. In
particular a change to a file or config option now only recompiles
and relinks the affected objects, no more spurious compiles.
CML2 support. The patch on sourceforge uses the Configuration Mini
Language 1 (CML1) code from kbuild 2.4. You can select either CML1
or CML2 support, but you have to get the current CML2 entries from
Eric Raymond's CML2 page, http://www.tuxedo.org/~esr/kbuild/. We
expect 2.5 kernels to support only CML2, so test CML2 now, while both
versions are available.
A far more robust mini language for the makefile fragments. Instead
of setting magic make variables and hoping that Rules.make does what
you expect, the Makefile.in files say what you want to do, it is up
to kbuild 2.5 to determine how to achieve your requirements.
Quiet mode. By default kbuild 2.5 outputs one line for each compile,
link or user defined command. The only other output is warnings and
errors which are now far easier to see. Of course, you can still see
the full commands if you really care.
Standard support for shipping generated files. kbuild 2.4 has had
continual problems with files that are both generated and shipped.
This is typically done where the generation process requires
utilities that not every user has installed. In kbuild 2.5 this
problem has a standard solution which should prevent recurrence of
the kbuild 2.4 problems.
Correct parallel running. You can do make -j on all commands and
kbuild 2.5 will ensure that commands are run in the correct order.
Multiple targets can be specified on the same make command. You
cannot mix clean or mrproper with other targets but everything else
can be put on one command.
make -j oldconfig installable && sudo make -j install
works beautifully.
Install targets such as bzImage, zImage, where to install System.map
and .config, the install path prefix, which commands to run after
install etc. are all CONFIG_ options. Copy .config from one kernel
to another, run make install and it all happens, hands free.
Users who require additional processing can dynamically specify
additional targets, at any point in the build cycle. This is useful
for running distribution specific code without hacking the makefiles.
You can compile individual targets at any level in the tree, which is
useful when you are hacking on code. Or you can compile everything
in a directory, with or without recursion into sub directories.
Unlike kbuild 2.4 make SUBDIRS=, the kbuild 2.5 method will not
create inconsistent kernels.
The kernel version number is only incremented when vmlinux is
rebuilt, not on every make.
You can rename the source and object directories without having to
recompile anything.
It is documented! Read Documentation/kbuild/kbuild-2.5.txt.
TODO:
Add other architectures. Release 1 only supports ix86. IA64 will be
next because I have access to a box. After that it will depend on
help from the arch support groups.
Patch for -ac kernel (maybe). It only needs to track changes to
makefiles in -ac, the core kbuild 2.5 code is the same for -ac
kernels.
Help to convert external sources to kbuild 2.5 format. XFS is
already converted, it will compile with either kbuild 2.4 or 2.5.
http://marc.theaimsgroup.com/?l=linux-xfs&m=99701265316648&w=2
Performance improvements. Some of the code has behaviour O(n**2) in
the number of objects being built. For a small compile, kbuild 2.5
is about 10% faster compared to 2.4 make dep + make bzImage. For a
full kernel compile, kbuild 2.5 is about twice as slow as kbuild 2.4.
I know where the problems are and am working on them. MEC mantra
Correctness comes first.
Then maintainability.
Then speed.
Add module symbol version support. The old genksyms was a nice idea
but the implementation has fundamental design problems and has been
removed. I will be adding clean module symbol version support later,
after kernel 2.5 has started. The correct implementation needs a new
version of modutils.
Remove incorrectly shipped files from the kernel tar ball.
Convert relative includes (#include "../..") to remove assumptions
about the structure of the kernel tree, this breaks when code is
moved around.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE7cOL4i4UHNye0ZOoRAij5AJ90j8PTsXz0+PsRz0jXMKp5fHnpOQCfaETG
kk3ylHmGewU+QsBDrBwkCq0=
=wcrs
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 15 2001 - 21:00:15 EST