Hello Bastien,
On 22/07/2025 15:03, Bastien Nocera wrote:
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
Thanks for these inputs. I agree that long term extending uapi is the
best option,
given this scenario.
I was not so much convinced of keeping the downstream patch into Yocto
recipe as it is extra
maintenance but I see your point. Showing there is already a workaround
in place can be further
motivation to approve the upstream.
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(+)
