| Message ID | 20241111173421.44377-3-gudni.m.g@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add support for Bluetooth sockets in Python | expand |
On Mon, 11 Nov 2024 at 18:34, Guðni Már Gilbert via lists.openembedded.org <gudni.m.g=gmail.com@lists.openembedded.org> wrote: > +# Enable support for AF_BLUETOOTH socket family > +DEPENDS:append:class-target = " ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez5-native', '', d)}" This is brittle and can be improved. If bluez5-native arrives into sysroot through some other way than the distro feature, then the python support will be quetly enabled even if it wasn't asked for. The correct way can be seen in e.g. strace recipe: PACKAGECONFIG[bluez] = "ac_cv_header_bluetooth_bluetooth_h=yes,ac_cv_header_bluetooth_bluetooth_h=no,bluez5" Alex
Thanks for the suggestion Alexander. I really appreciate it. Now that I have my bluetooth hardware running on master branch, I can easily test this. It will probably have to wait until the weekend though.
On Mon, 2024-11-11 at 17:34 +0000, Guðni Már Gilbert via lists.openembedded.org wrote: > When bluetooth is in DISTRO_FEATURES, Python should enable support for Bluetooth sockets > in the socket library. To enable AF_BLUETOOTH socket family and its protocols, bluetooth.h > header needs to be available at build-time. > > With this change a Python application can open and use Bluetooth sockets natively without > using 3rd party packages like pybluez. > > An example is the following line: > sock = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM, socket.BTPROTO_RFCOMM) > > With this patch the code will not fail due to missing symbols. > > Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com> > --- > meta/recipes-devtools/python/python3_3.13.0.bb | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/meta/recipes-devtools/python/python3_3.13.0.bb b/meta/recipes-devtools/python/python3_3.13.0.bb > index 54742f5257..8a98386576 100644 > --- a/meta/recipes-devtools/python/python3_3.13.0.bb > +++ b/meta/recipes-devtools/python/python3_3.13.0.bb > @@ -71,6 +71,9 @@ DEPENDS = "bzip2-replacement-native expat libffi bzip2 openssl sqlite3 zlib virt > DEPENDS:append:class-target = " python3-native" > DEPENDS:append:class-nativesdk = " python3-native" > > +# Enable support for AF_BLUETOOTH socket family > +DEPENDS:append:class-target = " ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez5-native', '', d)}" > + > EXTRA_OECONF = " --without-ensurepip --enable-shared --with-platlibdir=${baselib} --with-system-expat" > EXTRA_OECONF:append:class-native = " --bindir=${bindir}/${PN}" > EXTRA_OECONF:append:class-target = " --with-build-python=nativepython3" This doesn't make sense to be. You're adding a -native dependency for a target recipe. How is the target toolchain finding native headers? That sounds like a really bad idea... I appreciate there may be dependency issues but native headers shouldn't be accessed by target toolchains as it can cause all kinds of issues. Cheers, Richard
Hi Richard, I do agree with you, this feels like its not the "proper" solution. I am pretty sure you don't need python3 to build BlueZ, I suspect it has something to do with systemd. Perhaps we can optimise the DEPENDS in BlueZ recipe.
diff --git a/meta/recipes-devtools/python/python3_3.13.0.bb b/meta/recipes-devtools/python/python3_3.13.0.bb index 54742f5257..8a98386576 100644 --- a/meta/recipes-devtools/python/python3_3.13.0.bb +++ b/meta/recipes-devtools/python/python3_3.13.0.bb @@ -71,6 +71,9 @@ DEPENDS = "bzip2-replacement-native expat libffi bzip2 openssl sqlite3 zlib virt DEPENDS:append:class-target = " python3-native" DEPENDS:append:class-nativesdk = " python3-native" +# Enable support for AF_BLUETOOTH socket family +DEPENDS:append:class-target = " ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez5-native', '', d)}" + EXTRA_OECONF = " --without-ensurepip --enable-shared --with-platlibdir=${baselib} --with-system-expat" EXTRA_OECONF:append:class-native = " --bindir=${bindir}/${PN}" EXTRA_OECONF:append:class-target = " --with-build-python=nativepython3"
When bluetooth is in DISTRO_FEATURES, Python should enable support for Bluetooth sockets in the socket library. To enable AF_BLUETOOTH socket family and its protocols, bluetooth.h header needs to be available at build-time. With this change a Python application can open and use Bluetooth sockets natively without using 3rd party packages like pybluez. An example is the following line: sock = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM, socket.BTPROTO_RFCOMM) With this patch the code will not fail due to missing symbols. Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com> --- meta/recipes-devtools/python/python3_3.13.0.bb | 3 +++ 1 file changed, 3 insertions(+)