AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071025191649.6676e1d1@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<larry.scheer@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E056C916D@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 25 Oct 2007 19:18:36 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>
Subject: Re: Re-review of 26028
Message-ID: <20071025191836.4ddbfea5@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E056C916D@onstor-exch02.onstor.net>
References: <20071025180832.0fb0520e@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E056C916D@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 25 Oct 2007 19:11:53 -0700 "Larry Scheer"
<larry.scheer@onstor.com> wrote:

> Looks like I need to spend some time with you going over my changes
> and what needs to be done, explaining how it works and why I need to
> do things the way I did.
> 
> The linux/kernel Makefile needs work I don't think failing is the
> correct thing to do if you invoke make in the linux/kernel directory.
> Depending upon a hierarchical make is just wrong. If we spend some
> time together I think we can quickly come up with something we both
> like, for this Makefile.

It should work fine if invoked from there.  It works fine right now.
Unless you invoke it with PROD=ch or PROD=cattle or something.  And you
certainly don't want it to succeed then.

> Right now we can't build a cougar kernel until you get more of your
> stuff checked in. No sense rushing this. We will just have to put up
> with the nightly build failing for a while.

The nightly build worked somehow last night, and there haven't been any
changes since then.  Not to any of these makefiles.  So should work
again.

> -----Original Message-----
> From: Andy Sharp 
> Sent: Thursday, October 25, 2007 6:09 PM
> To: Larry Scheer
> Subject: Re: Re-review of 26028
> 
> On Thu, 25 Oct 2007 14:12:27 -0700 "Larry Scheer"
> <larry.scheer@onstor.com> wrote:
> 
> > Andy,
> >    I was not satisfied with the top level Makefile changes for the
> > kernel build. I decided to change the rules.
> > Please review these changes.
> > 
> > Also the kernel build would fail if the ROOTFS didn't exist so I
> > added a rule to make it.
> > 
> > Change 26028 by larrys@larrys on 2007/10/24 16:49:35 *pending*
> > 
> >         Change top level Linux kernel targets for specific products
> > to use an implicit rule and to call make kernel recursively
> > passing in
> >         PROD to the kernel target. 
> >         Added a default setting for TFTPDIR in case it is not passed
> > in or set in the environment.
> >         Reviewed by: AndyS
> > 
> > Affected files ...
> > 
> > ... //depot/dev/Makefile#2 edit
> > ... //depot/dev/linux/kernel/Makefile#7 edit
> 
> Makefile
> 
>      line 47: is that a trailing space?  yes, it is!  this just
>      needlessly re-invokes make.  i don't understand why any kernel
>      target in the top level makefile should proceed into linux/rootfs
>      directory.  probably shouldn't.
> 
>      kernel: kernel-bl # kernel-cg
> 
>      kernel-%:
>      	make -C linux/kernel $@ PROD=$*  (<-- $*? is that even
>      	right?)
> 
>      these targets in this directory don't invoke kernel-install,
>      so there are no rootfs dependencies.
> 
> linux/kernel/Makefile
> 
>      line 37
> 
>      no need for this stuff here, it just makes my life more
> difficult. this is caught in higher level makefiles.
> 
>      line 68
> 
>      the rootfs target is bogus: the make should die not knowing how
> to make rootfs, or, it should invoke make in the rootfs directory,
>      but doing a mkdir could be very bad right here.  i don't like
>      the mkdir $(rootfs)/boot either for the same reasons plus it's
>      procedural code that should be avoided in a makefile.  add /boot
>      to the end of the kernel-install dependency line like thus:
> 
>      kernel-install: $(KERNEL_FILES) $(ROOTFS)/boot
> 
>      and remove the test/mkdir line for the boot directory.  if rootfs
>      has been properly made, it is there, otherwise, make should fail.
> 
> 
