AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071025195555.705fba55@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	BB375AF679D4A34E9CA8DFA650E2B04E056C9171@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 25 Oct 2007 19:56:49 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>
Subject: Re: Re-review of 26028
Message-ID: <20071025195649.6d6caf80@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E056C9171@onstor-exch02.onstor.net>
References: <20071025193539.63b1a6b5@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E056C9171@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

OK, I can't seem to figure this out.  Seriously, just fix the top level
makefile minimally to not break the build, and keep the rest of this
changelist around so we can figure it out like you said next time I'm
in-office, which might not be until Monday or Tuesday.

Consider that change pre-reviewed by me.

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

> No nightly build will most likely fail. There is a bug in the top
> level Makefile. I needed to do:
> 
> make -C linux/rootfs DESTDIR=$(ROOTFS) TFTPDIR=$(TFTPDIR) PROD=bl
> kernel
> 
> and instead I did 
> make -C linux/rootfs DESTDIR=$(ROOTFS) TFTPDIR=$(TFTPDIR) PROD=bl $@
> 
> $@ is kernel-bl or kernel-cg
> 
> And I didn't create those targets in linux/rootfs.
> 
> It ran last night because Ken did not implement the change I sent him
> yesterday. He implemented it today. 
> 
> 
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Thursday, October 25, 2007 7:36 PM
> To: Larry Scheer
> Subject: Re: Re-review of 26028
> 
> I don't ever do a make kernel-install from there, or anywhere.  If
> someone is doing that, then yeah, they better have a ROOTFS, and if
> they don't, it should fail.  Then they can go fix that, and then go
> back and try it again.
> 
> The only time someone would be doing that is if they are working on
> the kernel.  That means they will be doing it over and over -- unless
> they're better than me -- and probably not to a standard ROOTFS, so it
> works perfectly for everybody.  Standard builds get what they want,
> and the occassional kernel dilatantes get what they want.
> 
> But the nightly build will go, yes?
> 
> On Thu, 25 Oct 2007 19:20:51 -0700 "Larry Scheer"
> <larry.scheer@onstor.com> wrote:
> 
> > No it only works fine for you because you are using a pre-existing
> > ROOTFS.
> > 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Thursday, October 25, 2007 7:19 PM
> > To: Larry Scheer
> > Subject: Re: Re-review of 26028
> > 
> > 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.
> > > 
> > > 
