bluez5_utils: add autoreconf back
PATCH 1/1 bluez5_utils: add autoreconf back
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.
---
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(+)
package/bluez5_utils/bluez5_utils.mk +1 -0
@@ -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 \
Signature · 1 line
2.10.2
PATCH 1/1 bluez5_utils: add autoreconf back
Hello,
Quoted 5 lines · Gary Bisson
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.
Quoted 8 lines
Forcing an autoreconf fixes such issue.
Signed-off-by Gary Bisson <[email protected]>---
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 :)
Quoted 12 lines
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
Quoted 7 lines
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.cisn'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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 bluez5_utils: add autoreconf back
Quoted 34 lines · Thomas Petazzoni
Hello,
Quoted 5 lines · Gary Bisson
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.
Quoted 8 lines
Forcing an autoreconf fixes such issue.
Signed-off-by Gary Bisson <[email protected]>---
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 :)
Quoted 15 lines
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/bluez5Now the idea is to provide a Boundary external layer that adds support for this chip in Buildroot.
Quoted 6 lines
Quoted 4 lines
When adding this patch, the builds fails since
hciattach_rome.cisn'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
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 bluez5_utils: add autoreconf back
Hello,
Quoted 4 lines · Arnout Vandecappelle
Quoted 1 line
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.
Quoted 2 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 bluez5_utils: add autoreconf back
Quoted 21 lines · Thomas Petazzoni
Hello,
Quoted 4 lines · Arnout Vandecappelle
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 2 lines
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
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 bluez5_utils: add autoreconf back
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Hi,
Quoted 13 lines
Quoted 5 lines
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
Makefilein
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.Quoted 2 lines
2. Imagine a mechanism that allows the "external" stuff to set autoreconf on a per-package basis.
Quoted 6 lines
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.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 bluez5_utils: add autoreconf back
Hi all,
Quoted 19 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Hi,
Quoted 14 lines
Quoted 5 lines
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
Makefilein
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.Quoted 2 lines
2. Imagine a mechanism that allows the "external" stuff to set autoreconf on a per-package basis.
Eek please no.
Quoted 7 lines
Quoted 4 lines
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
Makefileas 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