lkml.org 
[lkml]   [2002]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Update to the make rpm system kernel 2.4.17 and 2.5.1
Date
On Fri, 4 Jan 2002 15:05:37 -0500 (EST), 
pwd@mdtsoft.com wrote:
>I needed to be able to build a bit more complex set of rpm files than
>the make rpm function allowed. Attached is a patch that will replace
>the scripts/mkspec file with a perl program that generates a bit better
>spec file, the change to the top level Makefile that will use perl not
>bash for mkspec and a file for the Doc... directory explaining the changes.
>
>If there is anyone using the make rpm could take a look at this and let
>me know if it works with your build. I have tested this under a production
>build based on 2.4.17 and a build with default configuration under 2.5.1
>(I can't build any of my standard configuration for 2.5.1 due to buslogic
>dirver problems) and it does what I intended it to.

In kernel build 2.5 the make rpm target does not exist. kbuild 2.5
builds the kernel and modules, installs the kernel, modules, System.map
and .config, that is _all_ it does. Extra tasks like updating
bootloader files or building a package using the packaging method of
the month are _not_ part of kbuild 2.5. Every user wants to do
something different with bootloaders and packaging, there is no "one
size fits all" script.

Having said that, kbuild 2.5 is extensible. You can specify additional
targets and commands to do whatever special processing the user wants.
I have no problem with kbuild 2.5 shipping /sample/ scripts to do extra
processing, but it will not invoke them directly. Users copy the
sample code to their own directories and change it, then tell kbuild to
execute the copy that does exactly what this user wants. From
Documentation/kbuild/kbuild-2.5.txt:

ADDITIONAL TARGETS AND COMMANDS

Some users will want to execute additional commands as part of kbuild. In
particular users who generate kernel packages will want to run their own
commands after make install. Instead of polluting the kbuild Makefiles
with rules that have nothing to do with kernel building, kbuild 2.5
supports user defined additional commands, using variables ADD0 through
ADD9, with the corresponding ADD[0-9]_DEP and ADD[0-9]_CMD. A command like

make ADD0=pkg ADD0_DEP=install ADD0_CMD='my-package-script' pkg

Will make target 'pkg', which is defined by ADD0. It has a dependency
(ADD0_DEP) of install so the install process runs first. After install has
completed, command my-package-script (ADD0_CMD) is run. The command can be
shell commands separated by ';' but will normally be a distribution
specific script. The command has access to all the config variables plus
the variables that define the kernel, including KERNELRELEASE.

It is the responsibility of the packager to maintain their own scripts.
kbuild will not maintain scripts for every packaging manager used by every
distribution.

Because of the way that the .config variables are read by kbuild, you can
specify a CONFIG_ variable on the make command line and it will override
the value used by the makefiles. In general this is not safe because the
config values read during the compile stage are set by another mechanism so
overriding a config variable on the command line when that variable is used
in code will generate inconsistent results.

However there are some config variables that can be safely specified on the
make command line because they are only used by the makefiles. All these
variables start with CONFIG_INSTALL_, they define where the kernel,
modules, map, .config etc. are installed. Obviously a packaging system
will want to set some of these values on the command line. See the top
level Makefile.in for the current CONFIG_INSTALL_ variables.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.067 / U:2.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site