Re: [PATCH] netmap: support git-submodule build otption

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On Mon, 7 Oct 2019 at 11:50, Markus Armbruster <address@hidden> wrote:
>> Peter Maydell <address@hidden> writes:
>> > Basically new submodules are a pain so we seek to minimize
>> > the use of them.
>>
>> I suggested making it a submodule upthread[*].  Let me try to distill
>> the conversation into a rationale.  Giuseppe, please correct mistakes.
>>
>> To make use of QEMU's netmap backend (CONFIG_NETMAP), you have to build
>> and install netmap software from sources[**].  Which pretty much ensures
>> developers compile with CONFIG_NETMAP off, and the code rots.
>>
>> For other dependencies that aren't readily available on common
>> development hosts (slirp, capstone), we use submodules to avoid such
>> rot.  If the system provides, we use that, and if it doesn't, we fall
>> back to the submodule.  This has served us well.
>
> I would put this differently. We don't use submodules to avoid
> code-rot. We use submodules where a dependency is needed for us
> to provide QEMU features that are sufficiently important that we
> want to provide them to users even if those users don't have the
> dependency available to them as a system library.
>
> There are lots of features of QEMU that only compile with sufficiently
> recent versions of dependencies, and we don't try to submodule-ize
> them because the features aren't really that important for the bulk
> of our users. For instance, we provided pixman as a submodule for
> a while because the features that require it (our graphics layer
> code) are important to almost all users. But we didn't provide
> spice as a module even when you pretty much needed to be
> running bleeding-edge redhat to satisfy the version dependency
> we had, because most users don't care about spice support.

The ability to compile close to everything in a single build tree is
nevertheless convenient for developers.  Submodules aren't necessary for
that as long as "bleeding-edge redhat" can do the job.  And it pretty
much can: in my "everything" tree, config.status shows less than two
dozen "no", and most of them are uninteresting for compile-testing
(e.g. tcmalloc and jemalloc), or simply impossible to have (e.g. KVM is
for Linux, HAX is not for Linux, can't have both).  netmap's "no" is one
of the few that is due to missing dependencies.  Another one is vde.

> Shipping our dependencies as submodules imposes real costs
> on the project (for instance we then need to track the upstream
> to see when we should be updating, including checking whether
> we need to update to fix security issues). Submodules should be
> the exception, not the rule.

Point taken.

[...]