Hello Luiz,
Thanks for your feedbacks!
On 21/07/2025 17:20, Luiz Augusto von Dentz wrote:
Hi Francesco,
On Mon, Jul 21, 2025 at 11:24 AM Francesco Giancane
<quic_fgiancan@xxxxxxxxxxx> 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.
In theory what we should do to fix this is to add proper header to the
kernel, since libbluetooth is basically just used for syscalls to the
linux-bluetooth subsystem, btw doing that would also fix the likes of:
https://github.com/bluez/bluez/issues/989
I see I see. I read through these issues jumping back and forth Python
(it is interesting that it's covering the exact same case i'd like to
fix :)).
So if I understand correctly, your suggestion is to remove *our*
internal headers and rely solely on kernel ones? Or better, move ours
straight to the kernel UAPI.
I'd like to help here if you can provide more details I can work on a v2.
Thanks for your time,
`--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(+)
--
2.49.0.windows.1
