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? > > `--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(+)
