Re: [Qemu-devel] [PATCH slirp 0/5] Make it a standalone project
On Sun, 10 Feb 2019 at 22:03, Marc-André Lureau wrote: > Why do you think it should be a submodule? That's the approach I > proposed first, but Daniel suggested to make it immediately a shared > library if possible. It needs to be a submodule because you don't have a time machine to arrange for it to be an available package in all the stable versions of the distros we support. As and when it is packaged in the oldest stable versions we care about, we can drop the submodule, but submodule is where we need to start. (This is the same as we did with third party bits of code like pixman.) I think immediately going for the shared library (as opposed to static) is a bit of a bold decision also because it is a hard commitment to API and ABI compatibility, which previously has been something the slirp code didn't need to care about at all. > Regarding the build system, if meson/ninja is problematic for some > distro, we can come up with autotools or plain Make for a while. I think plain make would be more convenient. Otherwise everybody building QEMU needs to install a random extra build tool. thanks -- PMM
Re: [Qemu-devel] [PATCH slirp 0/5] Make it a standalone project
Hi On Sun, Feb 10, 2019 at 10:42 PM Peter Maydell wrote: > > On Sun, 10 Feb 2019 at 21:38, Samuel Thibault wrote: > > > > Hello, > > > > Peter Maydell, le dim. 10 févr. 2019 21:35:37 +, a ecrit: > > > On Fri, 8 Feb 2019 at 20:58, wrote: > > > > As discussed earlier in "[PATCH for-3.2 00/41] RFC: slirp: make it > > > > again a standalone project" and other threads, it would be useful to > > > > make slirp a separate project (the submodule approach was discarded) > > > > for various projects to share. > > > > > > > The following patches add meson build system (if necessary for older > > > > distros, autotools could be added - however I believe python & ninja > > > > are generally available on the QEMU supported platforms) > > > > > > Do you really need to make QEMU add an extra build dependency > > > just to use a different build system? > > > > AIUI, this patches series is meant for the slirp repository, not the > > QEMU repository. I.e. just to show how it'll look like, until a project > > it settled somewhere and the discussion can happen there. > > Yes, but we're going to be pulling it in as a submodule, > so a split out libslirp in its own repository with extra > build dependencies is harder to work with than one without. > Why do you think it should be a submodule? That's the approach I proposed first, but Daniel suggested to make it immediately a shared library if possible. Regarding the build system, if meson/ninja is problematic for some distro, we can come up with autotools or plain Make for a while. -- Marc-André Lureau
Re: [Qemu-devel] [PATCH slirp 0/5] Make it a standalone project
On Sun, 10 Feb 2019 at 21:38, Samuel Thibault wrote: > > Hello, > > Peter Maydell, le dim. 10 févr. 2019 21:35:37 +, a ecrit: > > On Fri, 8 Feb 2019 at 20:58, wrote: > > > As discussed earlier in "[PATCH for-3.2 00/41] RFC: slirp: make it > > > again a standalone project" and other threads, it would be useful to > > > make slirp a separate project (the submodule approach was discarded) > > > for various projects to share. > > > > > The following patches add meson build system (if necessary for older > > > distros, autotools could be added - however I believe python & ninja > > > are generally available on the QEMU supported platforms) > > > > Do you really need to make QEMU add an extra build dependency > > just to use a different build system? > > AIUI, this patches series is meant for the slirp repository, not the > QEMU repository. I.e. just to show how it'll look like, until a project > it settled somewhere and the discussion can happen there. Yes, but we're going to be pulling it in as a submodule, so a split out libslirp in its own repository with extra build dependencies is harder to work with than one without. thanks -- PMM
Re: [Qemu-devel] [PATCH slirp 0/5] Make it a standalone project
Hello, Peter Maydell, le dim. 10 févr. 2019 21:35:37 +, a ecrit: > On Fri, 8 Feb 2019 at 20:58, wrote: > > As discussed earlier in "[PATCH for-3.2 00/41] RFC: slirp: make it > > again a standalone project" and other threads, it would be useful to > > make slirp a separate project (the submodule approach was discarded) > > for various projects to share. > > > The following patches add meson build system (if necessary for older > > distros, autotools could be added - however I believe python & ninja > > are generally available on the QEMU supported platforms) > > Do you really need to make QEMU add an extra build dependency > just to use a different build system? AIUI, this patches series is meant for the slirp repository, not the QEMU repository. I.e. just to show how it'll look like, until a project it settled somewhere and the discussion can happen there. Samuel
Re: [Qemu-devel] [PATCH slirp 0/5] Make it a standalone project
On Fri, 8 Feb 2019 at 20:58, wrote: > As discussed earlier in "[PATCH for-3.2 00/41] RFC: slirp: make it > again a standalone project" and other threads, it would be useful to > make slirp a separate project (the submodule approach was discarded) > for various projects to share. > The following patches add meson build system (if necessary for older > distros, autotools could be added - however I believe python & ninja > are generally available on the QEMU supported platforms) Do you really need to make QEMU add an extra build dependency just to use a different build system? From my end that seems like just unnecessary pain for us (we're going to need to ship libslirp as a submodule for a while until it's been around long enough to be in stable distros, so its build dependencies will get added to QEMU's build deps). Is the standalone project going to provide a shared library or just a .a static library? (ie are you confident enough in the long-term stability of your API and ABI to do the shared library yet? the prudent approach might be to start with just the .a...) thanks -- PMM
Re: [Qemu-devel] [PATCH slirp 0/5] Make it a standalone project
Hello, marcandre.lur...@redhat.com, le ven. 08 févr. 2019 19:11:17 +0100, a ecrit: > Where should this new project be hosted? (I suggest some gitlab > instance, because of the nice ui/CI/issues/milestone...) I'd say freedesktop's gitlab would make a lot of sense yes, I'd go for it https://www.freedesktop.org/wiki/NewProject/ Samuel
