[Buildroot] [PATCH] bluez5_utils: add autoreconf back

[Buildroot] [PATCH] bluez5_utils: add autoreconf back

[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.

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(+)

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

[Buildroot] [PATCH] bluez5_utils: add autoreconf back

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] bluez5_utils: add autoreconf back

[Arnout Vandecappelle]

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

-- 
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

[Buildroot] [PATCH] bluez5_utils: add autoreconf back

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] bluez5_utils: add autoreconf back

[Arnout Vandecappelle]

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 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

[Buildroot] [PATCH] bluez5_utils: add autoreconf back

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] bluez5_utils: add autoreconf back

[Gary Bisson]

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