[qtconnectivity] make bluez mandatory on Linux

[miyanyan]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version, or no changes were necessary.
• Any fixed CI baseline and CI feature baseline entries are removed from that file, or no entries needed to be changed.
• All patch files in the port are applied and succeed.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

Fixes #51888

ref: https://doc.qt.io/qt-6/qtbluetooth-index.html

Building Qt Bluetooth
Even though the module can be built for all Qt platforms, the module is not ported to all of them. Non-supported platforms employ a dummy backend that is automatically selected when the platform is not supported. The dummy backend reports appropriate error messages and values, which enables you to detect at runtime that the current platform is not supported. The dummy backend is also selected on Linux if BlueZ development headers are not found during build time or Qt was built without Qt D-Bus support.
The usage of the dummy backend is highlighted via an appropriate warning while building and running.
Linux Specific
Since Qt 6.5 the Linux peripheral support has two backend alternatives: BlueZ DBus and Bluetooth Kernel API. The DBus backend is the default backend since Qt 6.7.
BlueZ DBus is the newer BlueZ stack and possibly the eventual successor of the older Kernel API. It is a bit more limited in terms of features, but in a typical usage this should not matter. One notable benefit of using the DBus backend is that the user process no longer needs to have the CAP_NET_ADMIN capability (for example by running as root user).
The DBus backend requires BlueZ version 5.56 or higher, and that it provides the needed DBus APIs. If these requirements are not met, Qt automatically falls back to the Bluetooth Kernel API backend.

[vicroms]

Suggested change

	"default-features": [
	{
	"name": "bluez",
	"platform": "linux"
	}
	],

The default feature changes behavior to depend on a system-installed dependency.

[miyanyan]

@vicroms I see qtbase[xcb] is the default feature on linux which requires system-installed xcb related dependencies, https://github.com/miyanyan/vcpkg/blob/22d9c655dc24ad24c6cac27607005e619ce46740/ports/qtbase/portfile.cmake#L55-L60

and bluez is also required by qtconnectivity on linux by default, I think it's ok to make bluez the default feature

Since Qt 6.5 the Linux peripheral support has two backend alternatives: BlueZ DBus and Bluetooth Kernel API. The DBus backend is the default backend since Qt 6.7.

[vicroms]

The name default features is unfortunately misguiding, they aren't intended to model upstream defaults. They are only intended to be used when otherwise a library would be non-functional (read more in our documentation).

Default features are hard for downstream consumers to disable, they must ensure that all upstream consumers of a library declare default-features: false in their vcpkg.json files, otherwise the default features get re-enabled.

If a feature is completely required, then it should be forcefully enabled in the portfile.cmake. If it's truly optional then it doesn't need to be a default feature.

set(ADDITIONAL_OPTIONS)
if (VCPKG_TARGET_IS_LINUX)
  message(WARNING "qtconnectivity[bluez] requires the BlueZ development headers from the system package manager. "
    "They can be installed on Debian/Ubuntu systems via sudo apt install libbluetooth-dev.")
  list(APPEND ADDITIONAL_OPTIONS FEATURE_bluez)
endif()


vcpkg_cmake_configure(
  OPTIONS
    ${FEATURE_OPTIONS}
    ${ADDITIONAL_OPTIONS}
)

[Neumann-A]

you also need CMAKE_REQUIRE_FIND_PACKAGE in the case the feature is activated

[Neumann-A]

you als need to control the FEATURE_ cmake flag qt uses for it

[miyanyan]

you also need CMAKE_REQUIRE_FIND_PACKAGE in the case the feature is activated

BlueZ is a system package that only provides pkg-config (.pc) files — it has no CMake config. So find_package(BlueZ REQUIRED) always fails, even when libbluetooth-dev is installed.

Qt's build system handles this correctly: qt_find_package(BlueZ PROVIDED_TARGETS PkgConfig::BLUEZ) first tries find_package(BlueZ) without REQUIRED, and when it returns NOTFOUND, falls back to pkg-config lookup which succeeds. Setting CMAKE_REQUIRE_FIND_PACKAGE_BlueZ=ON breaks this fallback by turning a non-fatal NOTFOUND into a hard error before pkg-config ever runs.

[Neumann-A]

You'll still need the FEATURE_ flag though. Otherwise it is a gamble if the feature is active or not.

[miyanyan]

@Neumann-A I removed CMAKE_DISABLE_FIND_PACKAGE_BlueZ, only use FEATURE_bluez

I checked the qt source code, there's a public feature bluez https://github.com/qt/qtconnectivity/blob/76613d577fd094258e1dc09746f39f92047faf79/src/bluetooth/configure.cmake#L44-L47

[dg0yt]

IIUC bluez becomes mandatory on Linux now. Please update the PR title so that it better describes the current changes.

[vicroms]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).