kernel: Added debian.chrome abstraction (version 2)

kernel: Added debian.chrome abstraction (version 2)

This version of the patch cleans up a bunch of debian installer cruft.

The built-in debian makefile system supports a number of handy targets, e.g.,

Generate the control files for packaging. You must do this before all else:
	fakeroot debian/rules clean

Build all flavours for the chroot arch:
	fakeroot debian/rules binary-debs

Generate a .config in debian/build/build-chromeos-intel-menlow:
	fakeroot debian/rules prepare-chromeos-intel-menlow

Generate the deb for this flavour: linux-image-2.6.31-0-chromeos-intel-menlow_2.6.31-0.1_i386.deb
	fakeroot debian/rules binary-chromeos-intel-menlow

Generate a .config in debian/build/build-chromeos-i386
	fakeroot debian/rules prepare-chromium-i386

Generate the deb for this flavour: linux-image-2.6.31-0-chromium-i386_2.6.31-0.1_i386.deb
	fakeroot debian/rules binary-chromium-i386

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>;

[tgardner, 2010-01-05 21:18:14]

As soon as everyone is happy with the way this works, I'll send an update to
chromiumos/src/scripts/build_kernel.sh that makes use of the hierarchical
configs. In the meantime this patch should not affect current builds.

P.S. this also includes the latest wireless debug config settings.

[Kevin Degi, 2010-01-11 20:33:25]

A few questions came up while I was working to get arm cross-compilation working
with this.

Is there a good way to use different defconfig's for different flavours?
Currently it appears that $defconfig can only be set to one defconfig target in
$(arch).mk. It looks like the only place this is used instead of the configs in
debian.chrome/config/ is when making the headers, so maybe only having one
defconfig there is acceptable.

Is it expected that you copy a config file to
debian.chrome/config/$(arch)/<flavour.config> and then run debian/rules
updateconfigs to extract the common variables, or is there another way to make
new configs work?

The linux-libc-dev entry in the control.stub.in file currently has Architecture
set to "i386 armel". This makes the build complain when build_arch and
header_arch are set to arm. Should we add "arm" to the list or change "armel" to
"arm", or do we need to look closer at the build system to make it work with the
control file the way it is?

[tgardner, 2010-01-11 22:46:18]

On 2010/01/11 20:33:25, Kevin Degi wrote:
> A few questions came up while I was working to get arm cross-compilation
working
> with this.
> 
> Is there a good way to use different defconfig's for different flavours?
> Currently it appears that $defconfig can only be set to one defconfig target
in
> $(arch).mk. It looks like the only place this is used instead of the configs
in
> debian.chrome/config/ is when making the headers, so maybe only having one
> defconfig there is acceptable.
> 

There isn't just one default target, though you can have the debian build
compile for _only_ one target, e.g.,

fakeroot debian/rules binary-debs flavours=chromium-i386

> Is it expected that you copy a config file to
> debian.chrome/config/$(arch)/<flavour.config> and then run debian/rules
> updateconfigs to extract the common variables, or is there another way to make
> new configs work?
> 

In order to initially create a set of hierarchical config files, copy the new
armel config to debian.chrome/config/armel/YOUR_FLAVOUR, then run 'fakeroot
debian/rules updateconfigs'. Make sure YOUR_FLAVOUR is listed in
debian.chrome/rules.d/armel.mk

> The linux-libc-dev entry in the control.stub.in file currently has
Architecture
> set to "i386 armel". This makes the build complain when build_arch and
> header_arch are set to arm. Should we add "arm" to the list or change "armel"
to
> "arm", or do we need to look closer at the build system to make it work with
the
> control file the way it is?

The linux-libc-dev entry is harmless and will probably disappear in the final
version.

[Mandeep Singh Baines, 2010-01-13 00:33:29]

What if we just patched debian.master instead? What are the pros/cons of
debian.chromeos versus debian.master?

[tgardner, 2010-01-13 09:24:13]

On 2010/01/13 00:33:29, msb wrote:
> What if we just patched debian.master instead? What are the pros/cons of
> debian.chromeos versus debian.master?

I expect that we'll want to rebase against Karmic again, so having a unique
directory will avoid conflicts in debian.master. I've used this particular
method to maintain other somewhat conflicting branches like fsl-imx51, mvl-dove,
ec2, etc.