qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 00/12] Convert over to use keycodemapdb


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v5 00/12] Convert over to use keycodemapdb
Date: Tue, 19 Sep 2017 11:08:39 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

On Mon, Sep 18, 2017 at 05:12:55PM +0200, Gerd Hoffmann wrote:
> On Thu, 2017-09-14 at 13:40 +0100, Daniel P. Berrange wrote:
> > On Thu, Sep 14, 2017 at 12:58:26PM +0100, Peter Maydell wrote:
> > > On 14 September 2017 at 12:55, Gerd Hoffmann <address@hidden>
> > > wrote:
> > > >   Hi,
> > > > 
> > > > > I think a better approach is to have something in rules.mak
> > > > > that ensures the submodule is checked out correctly (only
> > > > > when building from GIT, not dist), and then have the rules
> > > > > which generate the keymap files depend on this.
> > > > 
> > > > Care sending a patch doing that for dtc?
> > > 
> > > It sounds awfully fiddly. Maybe it is the best we can do
> > > given the mess that is git submodules, but is it really
> > > the common approach?
> > 
> > I'll do a prototype so we can see something concrete working and
> > evaluate how pleasant (or not) it is
> 
> Tried to brew something:
> 
> https://www.kraxel.org/cgit/qemu/log/?h=work/submodule
> 
> dtc was pretty simple due to the recursive make call.
> 
> Hooking the submodule update into a non-recursive make looks
> complicated, especially because the submodule update might change the
> timestamps and therefore the target set which needs a rebuild ...
> 
> So I did the keymaps build with a recursive make call too, which
> doesn't look that pretty ...

I don't think that's too ugly, but I wonder if there's some way to avoid
the recursive make call.

It feels like this is a similar scenario to 'config-host.mak' being
outdated. I don't entirely understand the logic yet, but we manage to
automatically re-run configure and rebuild config-host.make, when
configure changes, and that in turn affects which dependancies need
rebuild. I wonder if we can somehow integrate into that process, so
that configure is responsible for checking out the git submodules,
then make the re-running of configure trigger when .gitmodules
changes content.

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]