qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 00/11] Disassembler patches


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PULL 00/11] Disassembler patches
Date: Thu, 26 Oct 2017 11:06:45 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

On Thu, Oct 26, 2017 at 08:21:48AM +0100, Peter Maydell wrote:
> On 26 October 2017 at 08:06, Daniel P. Berrange <address@hidden> wrote:
> > I'm not sure what's giving you the 'pathspec' message though ? I would
> > expect anything to ignore the capstone dir - its just like any other
> > untracked file once you go back in time before it was committed.
> 
> Sorry, just realized that was the output of my filtering of the
> log. Here's what I should have quoted:
> 
> From git://git.linaro.org/people/pmaydell/qemu-arm
>  + a872ea5...6315472 staging    -> pmaydell/staging  (forced update)
> warning: unable to rmdir capstone: Directory not empty
> error: pathspec 'capstone' did not match any file(s) known to git.
> Did you forget to 'git add'?
> make: Entering directory `/home/pm215/qemu/build/all'
> config-host.mak is out-of-date, running configure
>   GIT     ui/keycodemapdb dtc capstone
> make[1]: *** No rule to make target `all'.  Stop.
> error: pathspec 'capstone' did not match any file(s) known to git.
> Did you forget to 'git add'?
> make: *** [git-submodule-update] Error 1
> make: *** Waiting for unfinished jobs....
> make: *** [subdir-capstone] Error 2
> Install prefix    /usr/local
> BIOS directory    /usr/local/share/qemu
> firmware path     /usr/local/share/qemu-firmware
> binary directory  /usr/local/bin
> [rest of configure output skipped]
> replication support yes
> VxHS block device no
> make: Leaving directory `/home/pm215/qemu/build/all'
> 
> It looks like the git update script thinks that there ought to
> be a 'capstone' submodule, which of course there isn't any more,
> so it barfs trying to update it.

Yeah, ok that makes more sense.  The 'config-host.mak' rules have the
list of desired submodules and those correspond to the state when you
ran configure with the patches applied.

Do we really expect make/configure todo the right thing when going
backwards in time ?  I've always assumed that if you go back in time
when you need to do a 'git clean -f -x d' and re-run configure from
scratch. Certainly in the past various makefile changes in QEMU would
break, or silently not correctly recompile stuff when going backwards
in time.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]