[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kbuild-devel
Subject:    Re: [kbuild-devel] [RFC] New kbuild commands
From:       Tom Rini <trini () kernel ! crashing ! org>
Date:       2001-08-16 8:37:05
[Download RAW message or body]

On Thu, Aug 16, 2001 at 10:34:05AM +1000, Keith Owens wrote:

> Looking at the existing Makefiles, this is because you want all the
> images in one place.  The solution is not to mv the image from chrp,
> because if you do mv then the next build or install has to recreate
> chrp/zImage.chrp.  Instead, in chrp you have

Ah, right.

> The 'installable' target is extended like this
> 
> installable: ($objfile /arch/$(ARCH)/boot/images/zImage.$(machtype))

Er, close I think.  Some targets have multiple 'installable' targets.
On some machines we need to produce a zImage for booting off a disk
or network and another for flash.  Other targets, such as CONFIG_ALL_PPC
need to produce binaries for differnet platforms.

> A trick to remember is that you can define all the build rules that you
> like, but if they are not required for a build then they are not
> executed.  This needs a different mindset from kbuild 2.4; with its
> recursive make and each run of make being independent you have to jump
> through hoops to stop things being built.  With a global makefile all
> those problems go away, you specify the top level targets to build and
> make decides which low level targets need to to {re-}built.  Low level
> targets that are not on the dependency graph for the top level target
> are ignored.

I'm sorta getting the hang of this. :)

> BTW, do you even need an images directory in kbuild 2.5?  Also do you
> need each zImage to have a mach-type suffix?  Each installable target
> can be in its own directory, the install process can pick up zImages
> for mach-type from mach-type/zImages.  No copy/link, no suffix on
> zImage.  Any reason we cannot do this?  It looks like the images
> directory is a workaround for recursive make problems.

As I stated above, we do have times where 1 CONFIG_platform will
produce multiple binaries, hence the suffix.  The main idea behind
the images directory was to try and put everything in one place.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

[prev in list] [next in list] [prev in thread] [next in thread]