Keith,
Even if Linus isn't ready for it to be included in the kernel, I am planning
to star releasing a patchset similar to that of Dave Jones. Kbuild will be
the first thing that I will work into my patchset. I will keep both ways of
building the kernel as I work on it, since another set of patches that I am
going to add breaks kbuild, until I fix it.
Matthew D. Pitts
----- Original Message -----
From: "Keith Owens" <kaos@ocs.com.au>
To: <linux-kernel@vger.kernel.org>
Cc: <torvalds@transmeta.com>
Sent: Tuesday, May 14, 2002 1:51 AM
Subject: kbuild 2.5 is ready for inclusion in the 2.5 kernel - take 2
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Content-Type: text/plain; charset=us-ascii
>
> Second attempt. Original sent on May 2, no response from Linus.
>
> Linus, kbuild 2.5 is ready for inclusion in the main 2.5 kernel tree.
> It is faster, better documented, easier to write build rules in, has
> better install facilities, allows separate source and object trees, can
> do concurrent builds from the same source tree and is significantly
> more accurate than the existing kernel build system.
>
> The current state is
>
> kbuild-2.5-core-14 Fits any 2.4 and 2.5 kernel.
> kbuild-2.5-common-2.5.15-3 2.5.15 arch independent files.
>
> There are several arch dependent files for 2.5.15 or earlier kernels.
>
> kbuild-2.5-i386-2.5.15-2
> kbuild-2.5-sparc64-2.5.15-1
> kbuild-2.5-s390-2.5.15-1
> kbuild-2.5-s390x-2.5.15-1
> kbuild-2.5-ppc-2.5.14-1
> kbuild-2.5-sh-2.5.12-1 (also fits 2.5.13)
> kbuild-2.5-ia64-2.5.10-020426-1 (last Mosberger patch)
>
> That covers most of the architectures that currently build on 2.5.
>
>
> This version has only been tested on CML1. kbuild 2.5 has support for
> an older version of CML2 but it has not been tested on newer versions
> of CML2.
>
> Before I send you the kbuild 2.5 patch, how do you want to handle it?
>
> * Coexist with the existing kernel build for one or two releases or
> delete the old build system when kbuild 2.5 goes in?
>
> Coexistence for a few days gives a backout, just in case. It also
> gives a kernel release where the old and new code can be compared,
> useful for architectures that have not been converted yet.
>
> Deleting the old system at the same time means that unconverted
> architectures cannot build. OTOH many architectures are already
> broken in the 2.5 kernel.
>
> * I need a quiet period of 24-48 hours (no changes at all) after a new
> kernel release to bring kbuild 2.5 up to the latest release, before
> sending you the complete patch. Which kernel release do you want
> kbuild 2.5 against?
>
> I would like kbuild 2.5 to go in in the near future. Keeping up to
> date with kernel changes is a significant effort, Makefiles change all
> the time, especially when major subsystems like sound and usb are
> reorganised. There are also some changes to architecture code to do it
> right under kbuild 2.5 and tracking those against kernel changes can be
> painful.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Exmh version 2.1.1 10/15/1999
>
> iD8DBQE84KXgi4UHNye0ZOoRAgucAKCAo9akupadD0YRWPly8HWxsB2FHwCgyXt5
> k31M4E5bhAhaFh3islVdik4=
> =O6CH
> -----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/
-
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 : Tue May 14 2002 - 12:00:22 EST