On 2/5/20 6:51 PM, Daniel P. Berrangé wrote: > On Wed, Feb 05, 2020 at 06:40:31PM +0100, Aleksandar Markovic wrote: >> On Sat, Feb 1, 2020 at 7:53 PM Philippe Mathieu-Daudé <f4bug@xxxxxxxxx> wrote: >>> >>>>>> @@ -1151,10 +1150,6 @@ for opt do >>>>>> ;; >>>>>> --enable-brlapi) brlapi="yes" >>>>>> ;; >>>>>> - --disable-bluez) bluez="no" >>>>>> - ;; >>>>>> - --enable-bluez) bluez="yes" >>>>>> - ;; >>>>> >>>>> Now than I'm bisecting over this commit, I realize removing this >>>>> option was not a good idea, we should have done like commit >>>>> cb6414dfec8 or 315d3184525: >>>>> >>>>> @@ -886,10 +885,6 @@ for opt do >>>>> - --disable-uuid) uuid="no" >>>>> - ;; >>>>> - --enable-uuid) uuid="yes" >>>>> - ;; >>>>> ... >>>>> + --enable-uuid|--disable-uuid) >>>>> + echo "$0: $opt is obsolete, UUID support is always built" >&2 >>>>> + ;; >>>> >>>> Looks trivial ... so if it bugs you, just send a patch? >>> >>> I thought about it but this won't fix much, it is too late now. >>> >>> I simply wanted to share this bugged me so we try to avoid doing the >>> same mistake again. >>> >> >> I vote for addition of a change similar to what Philippe described. >> >> Furthermore, it looks to me the correct way would be to now do full >> deprecation of --enable-bluez and --disable-bluez. This means adding >> this to documentation (not related to bluetooth devices support), not >> only a change in "configure". This also means that only after two next >> full cycles these options could be removed. >> >> True, this could have been done together with bluetooth devices >> support deprecation (and in that case we could have deleted these >> options right away), but it wasn't. Users don't have a crystal ball to >> know that we assumed that --enable-bluez and --disable-bluez were part >> of bluetooth devices support, and could rightfully complain about an >> abrupt elimination of a compile time option. > > The deprecation policy is primarily intended for notifying of changes > to QEMU's stable interfaces ( CLI, HMP, QMP) which affect behaviour > and usage of QEMU at runtime & are liable to break apps managing > QEMU. > > Changes to build time options have no strong reason to be subjected to > the deprecation process. If we remove an option at build time the effect > is noticed immediately and the solution is straightforward (stop passing > the option). We have added / removed configure options at will with little > negative feedback historically. We'll have far biggest changes coming to > the build system in future too, with the introduction of meson. I understand your point when looking forward (when distribution upgrade, it is easy to adapt). However this is still an issue when looking backward when running bisection to find regressions. > I don't think we want to constrain & complicate our work in modernizing > the build system by declaring that any changes to it must go through > deprecation. > > Regards, > Daniel >
