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

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