Re: [Qemu-devel] [PULL 0/2] slirp: move slirp as git submodule project

[Daniel P . Berrangé]

On Tue, May 07, 2019 at 09:11:09AM -0500, Eric Blake wrote:
> On 5/2/19 5:30 PM, Samuel Thibault wrote:
> > The following changes since commit 8482ff2eb3bb95020eb2f370a9b3ea26511e41df:
> > 
> >   Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' 
> > into staging (2019-05-02 12:04:51 +0100)
> > 
> > are available in the Git repository at:
> > 
> >   https://people.debian.org/~sthibault/qemu.git tags/samuel-thibault
> > 
> > for you to fetch changes up to 7c57bdd82026ba03f3158bbcd841afde7c2dc43a:
> > 
> >   build-sys: move slirp as git submodule project (2019-05-03 00:15:37 +0200)
> > 
> > ----------------------------------------------------------------
> > slirp: move slirp as git submodule project
> > 
> > Marc-André Lureau (2):
> >   build-sys: pass CFLAGS & LDFLAGS to subdir-slirp
> >   build-sys: move slirp as git submodule project
> > 
> > ----------------------------------------------------------------
> > Marc-André Lureau (2):
> >       build-sys: pass CFLAGS & LDFLAGS to subdir-slirp
> >       build-sys: move slirp as git submodule project
> 
> After this series, an in-tree build is seeing a dirty tree, thanks to:
> 
> > Changes not staged for commit:
> >   (use "git add <file>..." to update what will be committed)
> >   (use "git checkout -- <file>..." to discard changes in working directory)
> >   (commit or discard the untracked or modified content in submodules)
> > 
> >     modified:   slirp (untracked content)
> 
> which in reality is due to:
> 
> $ cd slirp/
> $ git status
> HEAD detached at 59a1b1f
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
> 
>       libslirp.a
>       src/arp_table.d
>       src/arp_table.o
> ...
> 
> libslirp probably needs a .gitignore for *.a, *.o, *.d, and
> src/libslirp-version.h
> 
> And actually getting it to apply during qemu's build will need another
> submodule update.
> 
> In the meantime, where do we stand on our goal of disabling in-tree builds?

The view was largely positive when we discussed it. So I think it just
needs someone to step up with a patch proposal, and at the start of the
dev cycle is a good time for such a change i guess.

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 :|