| Message ID | 20161205131504.28872-1-gary.bisson@boundarydevices.com |
|---|---|
| State | Not Applicable |
| Headers | show |
Hello, On Mon, 5 Dec 2016 14:15:04 +0100, Gary Bisson wrote: > 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@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. Indeed :) > 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. Have you tried adding BLUEZ5_AUTORECONF = YES to your external.mk file? Thanks, Thomas
On 05-12-16 21:32, Thomas Petazzoni wrote: > Hello, > > On Mon, 5 Dec 2016 14:15:04 +0100, Gary Bisson wrote: >> 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@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. > > Indeed :) > >> 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. > > Have you tried adding BLUEZ5_AUTORECONF = YES to your external.mk file? That won't work, because it's used in an ifeq in the autotools-package expansion, and external.mk is included after the packages. It does work if you put it in override.mk, but that's not convenient in an external. Regards, Arnout
Hello, On Mon, 5 Dec 2016 22:16:03 +0100, Arnout Vandecappelle wrote: > > Have you tried adding BLUEZ5_AUTORECONF = YES to your external.mk file? > > That won't work, because it's used in an ifeq in the autotools-package > expansion, and external.mk is included after the packages. Gah. > It does work if you put it in override.mk, but that's not convenient in an > external. I guess you wanted to say "local.mk" and not "override.mk", right? But in any case, I don't think we want to have a <pkg>_AUTORECONF = YES in a package "just in case" someone has patches against this package in his external tree. Otherwise, all autoconf packages should be <pkg>_AUTORECONF = YES. So, we've got two options here: 1. Say that having to change the original .mk file of a package in Buildroot is a fact of life if you add custom patches for this package. 2. Imagine a mechanism that allows the "external" stuff to set autoreconf on a per-package basis. Thomas
On 05-12-16 22:19, Thomas Petazzoni wrote: > Hello, > > On Mon, 5 Dec 2016 22:16:03 +0100, Arnout Vandecappelle wrote: > >>> Have you tried adding BLUEZ5_AUTORECONF = YES to your external.mk file? >> >> That won't work, because it's used in an ifeq in the autotools-package >> expansion, and external.mk is included after the packages. > > Gah. > >> It does work if you put it in override.mk, but that's not convenient in an >> external. > > I guess you wanted to say "local.mk" and not "override.mk", right? > > But in any case, I don't think we want to have a <pkg>_AUTORECONF = YES > in a package "just in case" someone has patches against this package in > his external tree. Otherwise, all autoconf packages should be > <pkg>_AUTORECONF = YES. > > So, we've got two options here: > > 1. Say that having to change the original .mk file of a package in > Buildroot is a fact of life if you add custom patches for this > package. Actually, for this particular case, it would be sufficient to patch Makefile in addition to Makefile.in. Which is a fact of life I'd say. We also sometimes have to do that when autoreconf doesn't work. > 2. Imagine a mechanism that allows the "external" stuff to set > autoreconf on a per-package basis. Eek please no. One thing I can imagine is that the expansion of the package infras is done later (after inclusion of external.mk). The first pass would just set variables, not define rules and definitely not use any ifdefs. The rules etc. would then have to avoid using $(1) $(2) etc, and just rely on $($(PKG)_NAME) and friends. Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, >> So, we've got two options here: >> >> 1. Say that having to change the original .mk file of a package in >> Buildroot is a fact of life if you add custom patches for this >> package. > Actually, for this particular case, it would be sufficient to patch Makefile in > addition to Makefile.in. Which is a fact of life I'd say. We also sometimes have > to do that when autoreconf doesn't work. >> 2. Imagine a mechanism that allows the "external" stuff to set >> autoreconf on a per-package basis. > Eek please no. > One thing I can imagine is that the expansion of the package infras is done > later (after inclusion of external.mk). The first pass would just set variables, > not define rules and definitely not use any ifdefs. The rules etc. would then > have to avoid using $(1) $(2) etc, and just rely on $($(PKG)_NAME) and friends. Lets not complicate things too much. Just patching Makefile as well and/or modifying the package is imho good enough.
Hi all, On Mon, Dec 5, 2016 at 11:39 PM, Peter Korsgaard <peter@korsgaard.com> wrote: >>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > > Hi, > > >> So, we've got two options here: > >> > >> 1. Say that having to change the original .mk file of a package in > >> Buildroot is a fact of life if you add custom patches for this > >> package. > > > Actually, for this particular case, it would be sufficient to patch Makefile in > > addition to Makefile.in. Which is a fact of life I'd say. We also sometimes have > > to do that when autoreconf doesn't work. > > >> 2. Imagine a mechanism that allows the "external" stuff to set > >> autoreconf on a per-package basis. > > > Eek please no. > > > One thing I can imagine is that the expansion of the package infras is done > > later (after inclusion of external.mk). The first pass would just set variables, > > not define rules and definitely not use any ifdefs. The rules etc. would then > > have to avoid using $(1) $(2) etc, and just rely on $($(PKG)_NAME) and friends. > > Lets not complicate things too much. Just patching Makefile as well > and/or modifying the package is imho good enough. Sure it's a solution but it's a shame I can't use the Yocto patch as-is. BTW, is Yocto always performing an autoreconf for autotools packages? The external.mk solution sounds interesting. Thanks for your interest in this case anyway. Regards, Gary
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 \
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@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(+)