On 05/02/2020 18.40, Aleksandar Markovic wrote: > On Sat, Feb 1, 2020 at 7:53 PM Philippe Mathieu-Daudé <f4bug@xxxxxxxxx> wrote: >> >> On Sat, Feb 1, 2020 at 7:51 PM Thomas Huth <thuth@xxxxxxxxxx> wrote: >>> On 01/02/2020 17.09, Philippe Mathieu-Daudé wrote: [...] >>>>> index 6099be1d84..ecce4ada2d 100755 >>>>> --- a/configure >>>>> +++ b/configure >>>>> @@ -349,7 +349,6 @@ unset target_list_exclude >>>>> # Distributions want to ensure that several features are compiled in, and it >>>>> # is impossible without a --enable-foo that exits if a feature is not found. >>>>> >>>>> -bluez="" >>>>> brlapi="" >>>>> curl="" >>>>> curses="" >>>>> @@ -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. Feel free to send a patch if it bugs you. > 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. I disagree. If you don't know that "bluez" is about bluetooth, then you should likely not use these options anyway. Thomas
