|Subject:||Re: deprecation of in-tree builds|
|Date:||Sat, 21 Mar 2020 23:45:12 +0100|
9:51 PM Sub, 21.03.2020. Peter Maydell <address@hidden> је написао/ла:
> AIUI from Paolo, the intention is to deprecate and eventually
> stop supporting "in-tree" builds, so that the only option is
> building in a separate build directory. I thought we should
> probably mention that in the 5.0 changelog, so I wrote up some
> Suggestions for changes/comments etc welcome.
> (One thing we will need to fix before we can do separate build
> tree is the Coverity Scan build process, which (a) does an
> in-tree build (b) can't be easily switched to a builddir because
> all the source paths get baked into the scan results and moving
> to a builddir changes them all...)
> We could also make configure actively warn if used in
> the source tree.
I don't intend to complain too much about removing in-tree builds, but there may be some not-so-visible, but valuable features that right now work in in-tree builds only, and I think we should make them work in out-of-tree builds as well.
For example, I noticed that gcov builds have some problems finding directories if built in out-of-tree, leading to no coverage report output at all, if applied to some external test executables (for some strange reasons, "make check" works for out-of-tree anf in-tree builds though). I think we should fix that and similar problems before removing in-tree builds.
In general, I also think we should not have overly lax treatment of features that may be effectively removed with any particular deprecation. Just because a feature is less-known or less-used is not a sufficient
reason IMHO to drop it just for the sake of "progress".
If the "progress" (in the form of deprecation) is so impotrant, than the authors should devise it so that there is no dammage to existing features, and no adverse effects.
In this light, perhaps in-tree builds deorecation is 5.0 is little premature.
> -- PMM
|[Prev in Thread]||Current Thread||[Next in Thread]|