On Fri, Sep 18, 2015 at 02:06:39PM +0200, Markus Armbruster wrote: > "Daniel P. Berrange" <berra...@redhat.com> writes: > > > On Fri, Sep 18, 2015 at 09:53:31AM +0100, Leon Alrae wrote: > >> On 18/09/2015 09:24, Daniel P. Berrange wrote: > >> > On Thu, Sep 17, 2015 at 07:38:53PM +0100, Peter Maydell wrote: > >> >> On 17 September 2015 at 19:21, Steve Ellcey <sell...@imgtec.com> wrote: > >> >>> > >> >>> Following up to my own email. Apparently the reason I get this error > >> >>> is > >> >>> that I am building with "--disable-tools --disable-system". I don't > >> >>> need > >> >>> the tools and I don't have pixman on my build system so if I don't use > >> >>> "--disable-tools --disable-system" I get an error about not having > >> >>> pixman > >> >>> installed. > >> >> > >> >> We ship pixman as a git submodule so that you don't have to have > >> >> a system pixman, though the configure options you're using should work. > >> >> > >> >>> When I do use "--disable-tools --disable-system" on the > >> >>> configure line I get: > >> >>> > >> >>> make[1]: *** No rule to make target `../qom/object.o', needed by > >> >>> `qemu-mips'. Stop. > >> >>> make: *** [subdir-mips-linux-user] Error 2 > >> >>> Error: Make command failed, stopping build. > >> >> > >> >> Daniel, this sounds like more fallout from your recent changes? > >> > > >> > I've just tried './configure --enable-tools --disable-system && make' and > >> > got a successful build, including the qemu-mips binary, so I wonder if > >> > there's some stale build artifacts, or other configure CLI args > >> > >> Note that Steve used --disable-tools, not enable. I just tried and it fails > >> also for me: > > > > Opps, when I tested, I *did* in fact use --disable-tools - just my email > > here was wrong. > > > >> $ ../qemu/configure --disable-tools --disable-system && make > >> (...) > >> make[1]: *** No rule to make target `../qom/object.o', needed by > >> `qemu-aarch64'. Stop. > >> make: *** [subdir-aarch64-linux-user] Error 2 > > > > Ahh, this is useful. > > > > You have your build directory *outside* the QEMU source tree, > > eg $GIT/../build, whereas I had been testing with $GIT/build > > and an non-VPATH build. > > > > I can in fact reproduce if building completely outside the GIT tree > > like you show. > > > > I'll look at producing a fix shortly... > > Dropping the in-tree build entirely would save us from such unnecessary > build breakages. Unfortunately, I haven't been able to find the time to > write a patch. Any takers?
Preventing non-VPATH builds wouldn't have avoided the breakage in this case, as it only occurred when multiple criteria were met. You needed to have done a build with certain features disabled *and* done it in a VPATH *and* for VPATH to have lived outside your $GIT checkout. We'd only catch that if we added more combinations to the build checks Peter does prior to merge. I could see an argument for dropping non-VPATH builds, even though I do typically use them myself, since VPATH vs non-VPATH is a constant source of trouble in most projects. I don't think its so reasonable to dictate to people /where/ they put their VPATHs - IMHO its acceptable to use $GIT/build as a VPATH. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
