Re: deprecation of in-tree builds

[BALATON Zoltan]

On Sun, 22 Mar 2020, Peter Maydell wrote:
> On Sun, 22 Mar 2020 at 19:52, Aleksandar Markovic
> <address@hidden> wrote:
> > If an end-user feature works only in in-tree builds (so,
> > explitely said: not in out-of-tree builds), this is not
> > a build-time stuff, but user-facing feature issue.
>
> gprof is a developer feature, not an end-user-facing
> feature. By the latter I mean "some feature that users
> who have installed a built binary might be using":
> command line stuff, actual functionality in the QEMU
> binary, QMP protocol, that kind of thing.
>
> > If someone is keen on removing any feature (as is truly in this case), I expect at least 
> > some moderate investigation being done on what could be affected (prior to announcing 
> > deprecation), rather than attitude "ok, let's announce deprecation, see if someone 
> > start clamoring, and, if not, we are good to go with removing". For me, this 
> > slightly disappointing.
>
> Before you told me about the gprof issue, the *only* thing

Was that gprof or gcov?

> I was aware of that might break was the coverity scan build,
> which is a purely project internal bit of infrastructure.

Plus potentially any scripts people might use to build stuff and distro 
packagers that might use in-tree build. They would suddently find their 
previously working scripts are now broken and they need to adapt. While 
making sure running configure; make; make install in source tree even if 
it actually does a build in a new build dir it creates automatically would 
be less annoying change than having to manually manage out-of-tree build 
dirs by those who did not do that so far.

Is it really that difficult to add a CI job to do a git clone then 
configure; make; make install in it to make sure it breaks less often? And 
to make sure this still works after in-tree builds are deprecated and 
removed? I think we can't check every distro packager or don't know what 
users do but supporting the usual way of building packages used by many 
may worth the little extra effort to not annoy users/developers 
unnecessarily.

Regards,
BALATON Zoltan