I don't know exactly what happened, but buildrom seems more fragile lately.
I used to be able to:
make menuconfig (select all options including a payload) make test it on QEMU make menuconfig (select a different payload) make etc.
Now I have to make clean after a payload switch. Is this by design?
Myles
On Fri, Apr 25, 2008 at 07:15:12AM -0600, Myles Watson wrote:
I don't know exactly what happened, but buildrom seems more fragile lately.
I used to be able to:
make menuconfig (select all options including a payload) make test it on QEMU make menuconfig (select a different payload) make etc.
Now I have to make clean after a payload switch. Is this by design?
Hmm. I've always had to do a make distclean && make to make sure that everything went well.
I'd argue this is a bug that needs fixing :)
Thanks, Ward.
-----Original Message----- From: Ward Vandewege [mailto:ward@gnu.org] Sent: Friday, April 25, 2008 7:45 AM To: Myles Watson Cc: 'Coreboot' Subject: Re: [coreboot] Buildrom seems more fragile
On Fri, Apr 25, 2008 at 07:15:12AM -0600, Myles Watson wrote:
I don't know exactly what happened, but buildrom seems more fragile
lately.
I used to be able to:
make menuconfig (select all options including a payload) make test it on QEMU make menuconfig (select a different payload) make etc.
Now I have to make clean after a payload switch. Is this by design?
Hmm. I've always had to do a make distclean && make to make sure that everything went well.
I'd argue this is a bug that needs fixing :)
I think it has to do with the .stamps/ files. Because they aren't removed during make clean, dependencies on the stamps make the next steps continue.
I'm not sure how to include that, though.
Myles
On Fri, Apr 25, 2008 at 08:53:19AM -0600, Myles Watson wrote:
Hmm. I've always had to do a make distclean && make to make sure that everything went well.
I'd argue this is a bug that needs fixing :)
I think it has to do with the .stamps/ files. Because they aren't removed during make clean, dependencies on the stamps make the next steps continue.
Yeah, that's not good, we should be removing those .configured files etc.
That's probably going to fix 'make clean', but it still won't fix 'make'. Should we automatically do a 'make clean' as part of every 'make' call?
Thanks, Ward.
-----Original Message----- From: Ward Vandewege [mailto:ward@gnu.org] Sent: Friday, April 25, 2008 9:12 AM To: Myles Watson Cc: 'Coreboot' Subject: Re: [coreboot] Buildrom seems more fragile
On Fri, Apr 25, 2008 at 08:53:19AM -0600, Myles Watson wrote:
Hmm. I've always had to do a make distclean && make to make sure that everything went well.
I'd argue this is a bug that needs fixing :)
I think it has to do with the .stamps/ files. Because they aren't
removed
during make clean, dependencies on the stamps make the next steps
continue.
Yeah, that's not good, we should be removing those .configured files etc.
That's probably going to fix 'make clean', but it still won't fix 'make'.
I thought make was broken because make clean was broken, but I could be wrong. I have more trouble when I use make clean then when I just run make again.
Should we automatically do a 'make clean' as part of every 'make' call?
I'd hate to do that. When I'm testing the tyan boards I don't want to make the kernel every time. Make clean removes the entire deploy directory.
Another problem we have is that we never check to see if deploy/$(PAYLOAD)-payload.elf is old. This leads to some unexpected behavior for me.
Thanks, Myles
On Fri, Apr 25, 2008 at 09:16:51AM -0600, Myles Watson wrote:
I thought make was broken because make clean was broken, but I could be wrong. I have more trouble when I use make clean then when I just run make again.
OK. What do you think of the attached patch?
Should we automatically do a 'make clean' as part of every 'make' call?
I'd hate to do that. When I'm testing the tyan boards I don't want to make the kernel every time. Make clean removes the entire deploy directory.
Yeah. You're right.
Another problem we have is that we never check to see if deploy/$(PAYLOAD)-payload.elf is old. This leads to some unexpected behavior for me.
Ugh. Also needs fixing I guess.
Thanks, Ward.
-----Original Message----- From: Ward Vandewege [mailto:ward@gnu.org] Sent: Friday, April 25, 2008 10:08 AM To: Myles Watson Cc: 'Coreboot' Subject: [PATCH] [buildrom] more 'make clean' fixes
On Fri, Apr 25, 2008 at 09:16:51AM -0600, Myles Watson wrote:
I thought make was broken because make clean was broken, but I could be wrong. I have more trouble when I use make clean then when I just run
make
again.
OK. What do you think of the attached patch?
I like it. Could you add coreinfo's .copied and kernel's .header?
With that change: Acked-by: Myles Watson mylesgw@gmail.com
Maybe we should remove the .unpacked stamp on a make distclean too?
Should we automatically do a 'make clean' as part of every 'make'
call?
I'd hate to do that. When I'm testing the tyan boards I don't want to
make
the kernel every time. Make clean removes the entire deploy directory.
Yeah. You're right.
Another problem we have is that we never check to see if deploy/$(PAYLOAD)-payload.elf is old. This leads to some unexpected behavior for me.
This may have been a side effect of something else. I'll check it again after we get some of these patches in.
Thanks, Myles
On Fri, Apr 25, 2008 at 10:49:29AM -0600, Myles Watson wrote:
I like it. Could you add coreinfo's .copied and kernel's .header?
Good catch!
With that change: Acked-by: Myles Watson mylesgw@gmail.com
Thanks, r167.
Maybe we should remove the .unpacked stamp on a make distclean too?
That should not be necessary - make distclean will wipe out the entire STAMP_DIR (well, actually the parent of STAMP_DIR). At least it does for the packages I checked; if there are where it does not do that, it's a bug.
Should we automatically do a 'make clean' as part of every 'make'
call?
I'd hate to do that. When I'm testing the tyan boards I don't want to
make
the kernel every time. Make clean removes the entire deploy directory.
Yeah. You're right.
Another problem we have is that we never check to see if deploy/$(PAYLOAD)-payload.elf is old. This leads to some unexpected behavior for me.
This may have been a side effect of something else. I'll check it again after we get some of these patches in.
Great.
Thanks, Ward.