On Sun, Mar 04, 2012 at 01:25:59PM +0000, Peter Maydell wrote: > On 4 March 2012 09:10, Michael S. Tsirkin <m...@redhat.com> wrote: > > I ended up with qmp-commands.h in target directories, > > which makes build fail as it is found before the > > main header. > > make clean fixes it, but it might get triggered > > again when we make some header target-independent next. > > It's easy to just make sure all such leftovers are > > removed, so let's do this. > > > > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > > > > diff --git a/Makefile b/Makefile > > index e66e885..958a414 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -89,6 +89,7 @@ qemu-options.def: $(SRC_PATH)/qemu-options.hx > > SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGET_DIRS)) > > > > subdir-%: $(GENERATED_HEADERS) > > + $(call quiet-command,rm -f $(foreach header, $(GENERATED_HEADERS), > > "$*/$(header)"),) > > $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $* V="$(V)" > > TARGET_DIR="$*/" all,) > > In general we don't have workarounds for "something > moved directory and this broke builds not from clean"
Why don't we? It's cheaper than always doing make clean after pull. > (source file moved from hw/ to . being one that's bitten > me before), Why would that bite anyone? AFAIK files under source control are handled fine. It's the generated ones that are a problem. > so why does just this one deserve to get an > rm here rather than just asking the user to run > 'make clean / distclean' ? > > -- PMM
