| Message ID | 4FC47539.4030905@redhat.com |
|---|---|
| State | New |
| Headers | show |
Il 29/05/2012 09:05, Gerd Hoffmann ha scritto: >> > I wonder if, independently of QOM, we also need to consider... >> > - qapi-generated/*.d, >> > - usb/*.d and >> > - tests/*.d? > Maybe we should just stop spreading the dep files over all directories? > RfC patch attached. This could in principle break, like hw/usb/core.o vs. hw/usb-core.o. It would be a very bad choice of names, but it is possible in principle. Another choice: we could just subst .o with .d in the *-obj-y variables. Paolo
Am 29.05.2012 09:44, schrieb Paolo Bonzini: > Il 29/05/2012 09:05, Gerd Hoffmann ha scritto: >>>> I wonder if, independently of QOM, we also need to consider... >>>> - qapi-generated/*.d, >>>> - usb/*.d and >>>> - tests/*.d? >> Maybe we should just stop spreading the dep files over all directories? >> RfC patch attached. > > This could in principle break, like hw/usb/core.o vs. hw/usb-core.o. It > would be a very bad choice of names, but it is possible in principle. I concur, it's quite risky for the final RC. Andreas
Am 29.05.2012 09:05, schrieb Gerd Hoffmann: > - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d > - rm -f qom/*.o qom/*.d > + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o > + rm -f qom/*.o I think this is calling for a centrally maintained (or automatically derived) list of build directories. Andreas
Il 29/05/2012 11:28, Andreas Färber ha scritto: > Am 29.05.2012 09:05, schrieb Gerd Hoffmann: >> - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d >> - rm -f qom/*.o qom/*.d >> + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o >> + rm -f qom/*.o > > I think this is calling for a centrally maintained (or automatically > derived) list of build directories. Quite difficult with the abuse of vpath that we currently have... but we can still proceed incrementally. Paolo
Am 29.05.2012 11:43, schrieb Paolo Bonzini: > Il 29/05/2012 11:28, Andreas Färber ha scritto: >> Am 29.05.2012 09:05, schrieb Gerd Hoffmann: >>> - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d >>> - rm -f qom/*.o qom/*.d >>> + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o >>> + rm -f qom/*.o >> >> I think this is calling for a centrally maintained (or automatically >> derived) list of build directories. > > Quite difficult with the abuse of vpath that we currently have... but we > can still proceed incrementally. For 1.1 I was thinking of something like BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom for dir in $(BUILDSUBDIRS); do \ rm -rf $dir/*.o $dir/*.d; \ done which possibly could also be reused for the list of *.d includes with some clever macro usage. Andreas
On 05/29/2012 04:47 AM, Andreas Färber wrote: > Am 29.05.2012 11:43, schrieb Paolo Bonzini: >> Il 29/05/2012 11:28, Andreas Färber ha scritto: >>> Am 29.05.2012 09:05, schrieb Gerd Hoffmann: >>>> - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d >>>> - rm -f qom/*.o qom/*.d >>>> + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o >>>> + rm -f qom/*.o >>> >>> I think this is calling for a centrally maintained (or automatically >>> derived) list of build directories. >> >> Quite difficult with the abuse of vpath that we currently have... but we >> can still proceed incrementally. > > For 1.1 I was thinking of something like > > BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom > > for dir in $(BUILDSUBDIRS); do \ > rm -rf $dir/*.o $dir/*.d; \ > done > > which possibly could also be reused for the list of *.d includes with > some clever macro usage. I'd prefer not to make this change in 1.1.0 as this doesn't seem to be a release blocker to me. I'd rather do something more significant in 1.2 and backport to a 1.1.1 release. Regards, Anthony Liguori > > Andreas >
Il 29/05/2012 11:47, Andreas Färber ha scritto: > Am 29.05.2012 11:43, schrieb Paolo Bonzini: >> Il 29/05/2012 11:28, Andreas Färber ha scritto: >>> Am 29.05.2012 09:05, schrieb Gerd Hoffmann: >>>> - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d >>>> - rm -f qom/*.o qom/*.d >>>> + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o >>>> + rm -f qom/*.o >>> >>> I think this is calling for a centrally maintained (or automatically >>> derived) list of build directories. >> >> Quite difficult with the abuse of vpath that we currently have... but we >> can still proceed incrementally. > > For 1.1 I was thinking of something like > > BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom > > for dir in $(BUILDSUBDIRS); do \ > rm -rf $dir/*.o $dir/*.d; \ > done > > which possibly could also be reused for the list of *.d includes with > some clever macro usage. I think even this is too much for 1.1. After all the problems come only if you modify the source, and right now 99.99% of the people will use the git tree for that. Paolo
Am 29.05.2012 11:50, schrieb Anthony Liguori: > On 05/29/2012 04:47 AM, Andreas Färber wrote: >> Am 29.05.2012 11:43, schrieb Paolo Bonzini: >>> Il 29/05/2012 11:28, Andreas Färber ha scritto: >>>> Am 29.05.2012 09:05, schrieb Gerd Hoffmann: >>>>> - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o >>>>> block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d >>>>> qapi/*.o qapi/*.d qga/*.o qga/*.d >>>>> - rm -f qom/*.o qom/*.d >>>>> + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o >>>>> qapi/*.o qga/*.o >>>>> + rm -f qom/*.o >>>> >>>> I think this is calling for a centrally maintained (or automatically >>>> derived) list of build directories. >>> >>> Quite difficult with the abuse of vpath that we currently have... but we >>> can still proceed incrementally. >> >> For 1.1 I was thinking of something like >> >> BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom >> >> for dir in $(BUILDSUBDIRS); do \ >> rm -rf $dir/*.o $dir/*.d; \ >> done >> >> which possibly could also be reused for the list of *.d includes with >> some clever macro usage. > > I'd prefer not to make this change in 1.1.0 as this doesn't seem to be a > release blocker to me. I'd rather do something more significant in 1.2 > and backport to a 1.1.1 release. Is "this change" referring to my patch, Gerd's attachment or my above snippet? I don't see it as a release blocker, but having proper dependencies in the release would be good for people patching the tarball. Andreas
On 05/29/2012 05:01 AM, Paolo Bonzini wrote: > Il 29/05/2012 11:47, Andreas Färber ha scritto: >> Am 29.05.2012 11:43, schrieb Paolo Bonzini: >>> Il 29/05/2012 11:28, Andreas Färber ha scritto: >>>> Am 29.05.2012 09:05, schrieb Gerd Hoffmann: >>>>> - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d >>>>> - rm -f qom/*.o qom/*.d >>>>> + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o >>>>> + rm -f qom/*.o >>>> >>>> I think this is calling for a centrally maintained (or automatically >>>> derived) list of build directories. >>> >>> Quite difficult with the abuse of vpath that we currently have... but we >>> can still proceed incrementally. >> >> For 1.1 I was thinking of something like >> >> BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom >> >> for dir in $(BUILDSUBDIRS); do \ >> rm -rf $dir/*.o $dir/*.d; \ >> done >> >> which possibly could also be reused for the list of *.d includes with >> some clever macro usage. > > I think even this is too much for 1.1. After all the problems come only > if you modify the source, and right now 99.99% of the people will use > the git tree for that. Agreed. I think this is 1.2 material with a possible backport to 1.1.x if we find a nice solution to the problem. Regards, Anthony Liguori > > Paolo >
diff --git a/Makefile b/Makefile index 9b7a85e..e872a8a 100644 --- a/Makefile +++ b/Makefile @@ -214,12 +214,12 @@ clean: # avoid old build problems by removing potentially incorrect old files rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f qemu-options.def - rm -f *.o *.d *.a *.lo $(TOOLS) $(HELPERS-y) qemu-ga TAGS cscope.* *.pod *~ */*~ + rm -f *.o .*.d *.a *.lo $(TOOLS) $(HELPERS-y) qemu-ga TAGS cscope.* *.pod *~ */*~ rm -Rf .libs - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d - rm -f qom/*.o qom/*.d + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o + rm -f qom/*.o rm -f qemu-img-cmds.h - rm -f trace/*.o trace/*.d + rm -f trace/*.o rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp @# May not be present in GENERATED_HEADERS rm -f trace-dtrace.h trace-dtrace.h-timestamp @@ -400,4 +400,4 @@ tar: rm -rf /tmp/$(FILE) # Include automatically generated dependency files --include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d qapi/*.d qga/*.d) +-include $(wildcard .*.d) diff --git a/rules.mak b/rules.mak index efef6f2..9937855 100644 --- a/rules.mak +++ b/rules.mak @@ -12,7 +12,7 @@ MAKEFLAGS += -rR %.mak: # Flags for dependency generation -QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(*D)/$(*F).d +QEMU_DGFLAGS += -MMD -MP -MT $@ -MF .$(subst /,-,$*).d %.o: %.c $(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<," CC $(TARGET_DIR)$@")