[Buildroot] [PATCH] bluez5_utils: add autoreconf back
Gary Bisson
gary.bisson at boundarydevices.com
Mon Dec 5 13:15:04 UTC 2016
Not necessary for an unmodified package. However if your external
layer includes BlueZ5 patches which brings new files (such as a
new hciattach protocol), it will not be built since the Makefile.in
is already there.
Forcing an autoreconf fixes such issue.
Signed-off-by: Gary Bisson <gary.bisson at boundarydevices.com>
---
Hi all,
I know this is a corner case which isn't a problem for 99% of users
so I won't be surprised if it is rejected.
The use case here is that we provide a WiFi/BT combo from Qualcomm
(QCA9377) which isn't supported in upstream BlueZ5.
https://boundarydevices.com/product/bd_sdmac_wifi/
Qualcomm said there was no plan to upstream the support, but provides
their own (outdated) tree in codeaurora:
https://source.codeaurora.org/quic/la/platform/external/bluetooth/bluez/
We generated a patch out of that repo that allows to add support for
this chip in Yocto (with a simple bbappend):
https://github.com/boundarydevices/meta-boundary/tree/krogoth/recipes-connectivity/bluez5/bluez5
Now the idea is to provide a Boundary external layer that adds support
for this chip in Buildroot.
When adding this patch, the builds fails since hciattach_rome.c isn't
specified in the Makefile.in already present in the archive.
Let me know if there's another opion in your opinion.
Regards,
Gary
---
package/bluez5_utils/bluez5_utils.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/bluez5_utils/bluez5_utils.mk b/package/bluez5_utils/bluez5_utils.mk
index 49cc7c2..af92926 100644
--- a/package/bluez5_utils/bluez5_utils.mk
+++ b/package/bluez5_utils/bluez5_utils.mk
@@ -11,6 +11,7 @@ BLUEZ5_UTILS_INSTALL_STAGING = YES
BLUEZ5_UTILS_DEPENDENCIES = dbus libglib2
BLUEZ5_UTILS_LICENSE = GPLv2+, LGPLv2.1+
BLUEZ5_UTILS_LICENSE_FILES = COPYING COPYING.LIB
+BLUEZ5_UTILS_AUTORECONF = YES
BLUEZ5_UTILS_CONF_OPTS = \
--enable-tools \
--
2.10.2
More information about the buildroot
mailing list