On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote: > Hello! > > On 22/07/2025 13:54, Bastien Nocera wrote: > > On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote: > > > Hi, > > > > > > I am posting this patch series to better decouple `bluetoothd` > > > daemon > > > and `libbluetooth`, as mentioned in the subject. > > > > > > I am introducing this change to make new BlueZ more granular. > > > This will allow more control on which components are actually > > > selected > > > to build. > > > > > > Major use case for this change is fixing circular dependencies > > > when > > > bootstrapping new builds where the whole build root is to be > > > recreated > > > (e.g. Yocto Project). > > > In these scenarios, to have Bluetooth support enabled in Python, > > > `libbluetooth` is required at build time to be present but the > > > direct > > > chain of dependencies would require a Python installation > > > available, > > > thus introducing circular dependency. > > > Separating the library and header files from the rest allows > > > build > > > systems to break the dependency loop. > > FWIW, I'm currently porting bluez to meson (currently stuck on > > porting > > ell with its gazillion of SSL certificate tests), which would make > > python a pre-requirement for bluez (if meson ended up being the > > only > > build system). > > > > What part of Python itself has Bluetooth support? Wouldn't it also > > be > > possible to make that part of Python separate so it can be built > > after > > bluez? > > Python uses autoconf to detect compile-time dependencies. > > They implemented Bluetooth network management with standard socket() > calls. > > This code path is enabled at compile time only if it detects > bluetooth.h > header. > > So for python to support Bluetooth in std library, libbluetooth > should > be already deployed. > > With this current patch series I posted, you can build a "lite" > version > of bluez to ship just enough > > the library and the headers so that python can have bluetooth support > (building a full BlueZ package requires > > python too... hence the circular dependency). Right, so you're trying to do: - bluez (lib and headers only) - python (with Bluetooth support) - bluez (full) And if meson were the only build system, you'd need to do: - python (without Bluetooth support) - bluez (full) - python (with Bluetooth support) I guess having a minimal uapi header upstream would allow to do: - python (with Bluetooth support) - bluez (full) Definitely the best option. I think it might be best to only migrate to the upstream kernel uapi the minimum needed to build Python with Bluetooth support, and extend it as needed afterwards. In the short-term, why not apply your bluez patches to your bluetoothd recipe rather than upstream? That should also motivate developers to land the "correct" fix upstream ;) Cheers > > Francesco > > > > > > `--enable-bluetoothd` flag is added to the `configure` script and > > > it is keeping the same behavior as other flags. > > > > > > Francesco Giancane (3): > > > configure.ac: introduce `--enable-bluetoothd` flag > > > Makefile.am: build `bluetoothd` if enabled > > > README: document `--enable-bluetoothd` flag > > > > > > Makefile.am | 8 ++++++++ > > > README | 14 ++++++++++++++ > > > configure.ac | 4 ++++ > > > 3 files changed, 26 insertions(+)
