Re: deprecation of in-tree builds

[Paolo Bonzini]

On 20/08/20 18:14, Kevin Wolf wrote:
> I just don't understand why 99.9% of it were okay to do, but the final
> bit that would make the switch a lot more seamless to people is asking
> too much. You're familiar with the state after your patches, I'm not. I
> assume you're also the one who sends the pull request, and anything
> developed after that pull request will mean that people will already
> be impacted.

Because that 99.9% was done according to a plan of avoiding half-baked
solutions, and only make decisions during the initial conversion that
are maintainable in the long term.  All the design and the work came
from that one principle.

Since total parity just cannot be attained (because Meson just hollers
and exits if you try to do an in-tree build, or because Meson just
places binaries mirroring the layout of source tree), anything that
tries to mimic of the previous buildsystem in unsupported ways is
half-baked by definition.

Some half-baked solutions are easy, and can be accomodated.  For example
take "Meson produces qemu-system-arm and tutorials says the binary is
arm-softmmu/qemu-system-arm", which Peter requested.  I would have
gladly done without it if it was just for Peter's muscle memory, :) but
the issue with tutorials is a fair one.  It's literally 3 lines of code
and I can add them easily.

Dropping in-tree builds is also an issue with respect to tutorials.
However, dropping support for in-tree builds simply requires a
good-enough warning and it can be done just before the release because
people using tutorials rarely build from git master.

If it's a matter of "I don't want my workflow to change too much", I'm
not familiar with everybody's setups and requirements and it's not a
precise-enough requirement for me to write the code (and block the
inclusion of the pull request).

What you're asking is not the final 0.1%; it's a completely different
thing, because it _must_ be by definition half-baked.  For example here
are all the tradeoffs that come to mind:

- given the argument about tutorials, should the in-tree "./configure &&
make" support extend to linking binaries back from the build tree?  All
binaries or only binaries that existed at the time of the conversion?
Should the linked binaries be placed in arm-softmmu/qemu-system-arm or
should it be in ./qemu-system-arm?  Any of this choices introduces
potential confusion to whoever follows a tutorial so, arguably, a
warning would be better than a half-baked solution inasmuch as tutorials
are concerned.

- if binaries are linked back, should they be kept in .gitignore?

- should distclean also be kept in GNUMakefile? (probably, since
distclean is _especially_ useful for in-tree builds)

- who is responsible to fix it if the support bitrots? (it will,
especially since with Meson things like adding a binary only require
touching one place: nobody will remember to add the binary to GNUMakefile)

- should I also add a CI job that tests it?

I'm rather happier to spend my time explaining details of the conversion
if they have to hack on the build system in the near future, than to
gather a detailed answer to these questions and any other that didn't
come to mind.

> If you ask me to do pause my work, instead familiarise myself with your
> work and do that final bit so that you can then include it in your pull
> request, I'm sure your employer will pay for more time being spent
> rather than less.

You don't need to familiarize with my work, you only need to familiarize
yourself with out-of-tree builds which almost everyone else is using[1].
 With out-of-tree builds, there is arguably no change whatsoever for
day-to-day development (as long as you don't touch the build system of
course).

Thanks,

Paolo

[1] For example, among the people in this thread who were using in-tree
builds, Stefan is using meson for his new project so presumably has
switched to out-of-tree builds, and Eric has already switched to
out-of-tree builds.