[Buildroot] [PATCH] hidapi: new package

[Buildroot] [PATCH] hidapi: new package

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 package/Config.in          |    1 +
 package/hidapi/Config.in   |   20 ++++++++++++++++++++
 package/hidapi/hidapi.hash |    2 ++
 package/hidapi/hidapi.mk   |   27 +++++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 0 deletions(-)
 create mode 100644 package/hidapi/Config.in
 create mode 100644 package/hidapi/hidapi.hash
 create mode 100644 package/hidapi/hidapi.mk

diff --git a/package/Config.in b/package/Config.in
index bdc3063..04800c5 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -864,6 +864,7 @@ menu "Hardware handling"
 	source "package/ccid/Config.in"
 	source "package/dtc/Config.in"
 	source "package/gnu-efi/Config.in"
+	source "package/hidapi/Config.in"
 	source "package/lcdapi/Config.in"
 	source "package/libaio/Config.in"
 	source "package/libatasmart/Config.in"
diff --git a/package/hidapi/Config.in b/package/hidapi/Config.in
new file mode 100644
index 0000000..7fbc1c2
--- /dev/null
+++ b/package/hidapi/Config.in
@@ -0,0 +1,20 @@
+config BR2_PACKAGE_HIDAPI
+	bool "hidapi"
+	depends on BR2_PACKAGE_HAS_UDEV
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libusb
+	select BR2_PACKAGE_LIBUSB
+	# When eudev is used as the udev provider, libgudev is
+	# automatically provided as it is part of eudev. However, when
+	# systemd is used as the udev provider, libgudev is not
+	# provided, and needs to be built separately. This is why we
+	# select the libgudev package only if systemd is used.
+	select BR2_PACKAGE_LIBGUDEV if BR2_PACKAGE_SYSTEMD
+	help
+	  HIDAPI is a multi-platform library which allows an application
+	  to interface with USB and Bluetooth HID-Class devices on
+	  Windows, Linux, and Mac OS X.
+
+	  http://www.signal11.us/oss/hidapi/
+
+comment "hidapi needs udev /dev management and a toolchain w/ threads"
+	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_HAS_UDEV
diff --git a/package/hidapi/hidapi.hash b/package/hidapi/hidapi.hash
new file mode 100644
index 0000000..ba00df2
--- /dev/null
+++ b/package/hidapi/hidapi.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 33e206f5e145fc1bc6aeb55084d71b55d686533d23ad5bb762746ceba81e728b  hidapi-d17db57b9d4354752e0af42f5f33007a42ef2906.tar.gz
diff --git a/package/hidapi/hidapi.mk b/package/hidapi/hidapi.mk
new file mode 100644
index 0000000..23d5eab
--- /dev/null
+++ b/package/hidapi/hidapi.mk
@@ -0,0 +1,27 @@
+################################################################################
+#
+# hidapi
+#
+################################################################################
+
+# Use master version as the current stable is very old and some bugs
+# have been fixed since then.
+HIDAPI_VERSION = d17db57b9d4354752e0af42f5f33007a42ef2906
+HIDAPI_SITE = $(call github,signal11,hidapi,$(HIDAPI_VERSION))
+HIDAPI_INSTALL_STAGING = YES
+# No configure provided, so we need to autoreconf.
+HIDAPI_AUTORECONF = YES
+HIDAPI_LICENSE = GPLv3, BSD-3c
+HIDAPI_LICENSE_FILES = LICENSE.txt LICENSE-gpl3.txt LICENSE-bsd.txt
+
+HIDAPI_DEPENDENCIES = libusb
+# When eudev is used as the udev provider, libgudev is automatically
+# provided as it is part of eudev. However, when systemd is used as the
+# udev provider, libgudev is not provided, and needs to be built
+# separately. This is why we select the libgudev package only if systemd
+# is used.
+ifeq ($(BR2_PACKAGE_SYSTEMD),y)
+HIDAPI_DEPENDENCIES += libgudev
+endif
+
+$(eval $(autotools-package))
-- 
1.7.1

[Buildroot] [PATCH] hidapi: new package

[Baruch Siach]

Hi Vincent,

On Mon, Nov 16, 2015 at 04:54:12PM +0000, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>

[...]

> +HIDAPI_DEPENDENCIES = libusb
> +# When eudev is used as the udev provider, libgudev is automatically
> +# provided as it is part of eudev. However, when systemd is used as the
> +# udev provider, libgudev is not provided, and needs to be built
> +# separately. This is why we select the libgudev package only if systemd
> +# is used.
> +ifeq ($(BR2_PACKAGE_SYSTEMD),y)

Should be 'ifeq ($(BR2_PACKAGE_LIBGUDEV),y)', in think, since all we need is 
to have libgudev built before this package, regardless of systemd. With this 
change the comment becomes redundant. The comment in Config.in should be 
enough.

> +HIDAPI_DEPENDENCIES += libgudev
> +endif

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH] hidapi: new package

[Vicente Olivert Riera]

Hello Baruch,

On 11/16/2015 06:07 PM, Baruch Siach wrote:
> Hi Vincent,
> 
> On Mon, Nov 16, 2015 at 04:54:12PM +0000, Vicente Olivert Riera wrote:
>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> 
> [...]
> 
>> +HIDAPI_DEPENDENCIES = libusb
>> +# When eudev is used as the udev provider, libgudev is automatically
>> +# provided as it is part of eudev. However, when systemd is used as the
>> +# udev provider, libgudev is not provided, and needs to be built
>> +# separately. This is why we select the libgudev package only if systemd
>> +# is used.
>> +ifeq ($(BR2_PACKAGE_SYSTEMD),y)
> 
> Should be 'ifeq ($(BR2_PACKAGE_LIBGUDEV),y)', in think, since all we need is 
> to have libgudev built before this package, regardless of systemd. With this 
> change the comment becomes redundant. The comment in Config.in should be 
> enough.

we need libgudev only if we are going to use systemd. Otherwise it will
be provided by eudev.

Of course we could use ifeq ($(BR2_PACKAGE_LIBGUDEV),y) here, but, for
consistency with Config.in, I use ifeq ($(BR2_PACKAGE_SYSTEMD),y)
instead. See for instance the udisks package.

Regards,

Vincent.

>> +HIDAPI_DEPENDENCIES += libgudev
>> +endif
> 
> baruch
> 

[Buildroot] [PATCH] hidapi: new package

[Baruch Siach]

Hi Vincent,

On Tue, Nov 17, 2015 at 10:11:26AM +0000, Vicente Olivert Riera wrote:
> On 11/16/2015 06:07 PM, Baruch Siach wrote:
> > On Mon, Nov 16, 2015 at 04:54:12PM +0000, Vicente Olivert Riera wrote:
> >> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> > 
> > [...]
> > 
> >> +HIDAPI_DEPENDENCIES = libusb
> >> +# When eudev is used as the udev provider, libgudev is automatically
> >> +# provided as it is part of eudev. However, when systemd is used as the
> >> +# udev provider, libgudev is not provided, and needs to be built
> >> +# separately. This is why we select the libgudev package only if systemd
> >> +# is used.
> >> +ifeq ($(BR2_PACKAGE_SYSTEMD),y)
> > 
> > Should be 'ifeq ($(BR2_PACKAGE_LIBGUDEV),y)', in think, since all we need is 
> > to have libgudev built before this package, regardless of systemd. With this 
> > change the comment becomes redundant. The comment in Config.in should be 
> > enough.
> 
> we need libgudev only if we are going to use systemd. Otherwise it will
> be provided by eudev.
> 
> Of course we could use ifeq ($(BR2_PACKAGE_LIBGUDEV),y) here, but, for
> consistency with Config.in, I use ifeq ($(BR2_PACKAGE_SYSTEMD),y)
> instead. See for instance the udisks package.

I think this is wrong. First, consistency with Config.in calls for using 
BR2_PACKAGE_LIBGUDEV like we do with all other selects. But more importantly, 
IMO, we only use the <pkg>_DEPENDENCIES variable to set the build order which 
is conceptually independent of the underlying reason we need this dependency, 
systemd in this case. I think that all the other packages that Thomas 
mentioned should also test for BR2_PACKAGE_LIBGUDEV when setting 
<pkg>_DEPENDENCIES.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH] hidapi: new package

[Thomas Petazzoni]

Baruch,

On Wed, 18 Nov 2015 06:50:51 +0200, Baruch Siach wrote:

> > Of course we could use ifeq ($(BR2_PACKAGE_LIBGUDEV),y) here, but, for
> > consistency with Config.in, I use ifeq ($(BR2_PACKAGE_SYSTEMD),y)
> > instead. See for instance the udisks package.
> 
> I think this is wrong. First, consistency with Config.in calls for using 
> BR2_PACKAGE_LIBGUDEV like we do with all other selects. But more
> importantly, IMO, we only use the <pkg>_DEPENDENCIES variable to set
> the build order which is conceptually independent of the underlying
> reason we need this dependency, systemd in this case. I think that
> all the other packages that Thomas mentioned should also test for
> BR2_PACKAGE_LIBGUDEV when setting <pkg>_DEPENDENCIES.

I am not as clear-cut as you are on what is the correct thing to do
here, but your reasoning seems reasonable to me. So we need to align
the existing packages to do this, and also to use BR2_INIT_SYSTEMD in
Config.in (udisks uses BR2_PACKAGE_SYSTEMD). Will you send some patches
or should I do so?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] hidapi: new package

[Baruch Siach]

Hi Thomas,

On Wed, Nov 18, 2015 at 09:22:10AM +0100, Thomas Petazzoni wrote:
> On Wed, 18 Nov 2015 06:50:51 +0200, Baruch Siach wrote:
> > > Of course we could use ifeq ($(BR2_PACKAGE_LIBGUDEV),y) here, but, for
> > > consistency with Config.in, I use ifeq ($(BR2_PACKAGE_SYSTEMD),y)
> > > instead. See for instance the udisks package.
> > 
> > I think this is wrong. First, consistency with Config.in calls for using 
> > BR2_PACKAGE_LIBGUDEV like we do with all other selects. But more
> > importantly, IMO, we only use the <pkg>_DEPENDENCIES variable to set
> > the build order which is conceptually independent of the underlying
> > reason we need this dependency, systemd in this case. I think that
> > all the other packages that Thomas mentioned should also test for
> > BR2_PACKAGE_LIBGUDEV when setting <pkg>_DEPENDENCIES.
> 
> I am not as clear-cut as you are on what is the correct thing to do
> here, but your reasoning seems reasonable to me. So we need to align
> the existing packages to do this, and also to use BR2_INIT_SYSTEMD in
> Config.in (udisks uses BR2_PACKAGE_SYSTEMD). Will you send some patches
> or should I do so?

I'll send the patches later. Would you like one patch per package, or a single 
patch based on next?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH] hidapi: new package

[Thomas Petazzoni]

Dear Baruch Siach,

On Wed, 18 Nov 2015 10:45:17 +0200, Baruch Siach wrote:

> > I am not as clear-cut as you are on what is the correct thing to do
> > here, but your reasoning seems reasonable to me. So we need to align
> > the existing packages to do this, and also to use BR2_INIT_SYSTEMD in
> > Config.in (udisks uses BR2_PACKAGE_SYSTEMD). Will you send some patches
> > or should I do so?
> 
> I'll send the patches later. Would you like one patch per package, or a single 
> patch based on next?

I think a single patch is good enough, the number of affected packages
is pretty small.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] hidapi: new package

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Mon, 16 Nov 2015 16:54:12 +0000, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  package/Config.in          |    1 +
>  package/hidapi/Config.in   |   20 ++++++++++++++++++++
>  package/hidapi/hidapi.hash |    2 ++
>  package/hidapi/hidapi.mk   |   27 +++++++++++++++++++++++++++
>  4 files changed, 50 insertions(+), 0 deletions(-)
>  create mode 100644 package/hidapi/Config.in
>  create mode 100644 package/hidapi/hidapi.hash
>  create mode 100644 package/hidapi/hidapi.mk

Applied to next, with a few changes:

    [Thomas:
     - use BR2_INIT_SYSTEMD instead of BR2_PACKAGE_SYSTEMD for the
       libgudev handling. This is consistent with what we do in libmbim,
       modem-manager and network-manager. Only udisks is diverging from
       this by using BR2_PACKAGE_SYSTEMD.
     - Fix the license info: it is GPLv3 *or* BSD-3c *or* the specific
       HIDAPI license. Added LICENSE-orig.txt to LICENSE_FILES.]

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] hidapi: new package

[Alan Ott]

On 11/16/2015 11:54 AM, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>   package/Config.in          |    1 +
>   package/hidapi/Config.in   |   20 ++++++++++++++++++++
>   package/hidapi/hidapi.hash |    2 ++
>   package/hidapi/hidapi.mk   |   27 +++++++++++++++++++++++++++
>   4 files changed, 50 insertions(+), 0 deletions(-)
>   create mode 100644 package/hidapi/Config.in
>   create mode 100644 package/hidapi/hidapi.hash
>   create mode 100644 package/hidapi/hidapi.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index bdc3063..04800c5 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -864,6 +864,7 @@ menu "Hardware handling"
>   	source "package/ccid/Config.in"
>   	source "package/dtc/Config.in"
>   	source "package/gnu-efi/Config.in"
> +	source "package/hidapi/Config.in"
>   	source "package/lcdapi/Config.in"
>   	source "package/libaio/Config.in"
>   	source "package/libatasmart/Config.in"
> diff --git a/package/hidapi/Config.in b/package/hidapi/Config.in
> new file mode 100644
> index 0000000..7fbc1c2
> --- /dev/null
> +++ b/package/hidapi/Config.in
> @@ -0,0 +1,20 @@
> +config BR2_PACKAGE_HIDAPI
> +	bool "hidapi"
> +	depends on BR2_PACKAGE_HAS_UDEV
> +	depends on BR2_TOOLCHAIN_HAS_THREADS # libusb
> +	select BR2_PACKAGE_LIBUSB
> +	# When eudev is used as the udev provider, libgudev is
> +	# automatically provided as it is part of eudev. However, when
> +	# systemd is used as the udev provider, libgudev is not
> +	# provided, and needs to be built separately. This is why we
> +	# select the libgudev package only if systemd is used.
> +	select BR2_PACKAGE_LIBGUDEV if BR2_PACKAGE_SYSTEMD
> +	help
> +	  HIDAPI is a multi-platform library which allows an application
> +	  to interface with USB and Bluetooth HID-Class devices on
> +	  Windows, Linux, and Mac OS X.
> +
> +	  http://www.signal11.us/oss/hidapi/
> +
> +comment "hidapi needs udev /dev management and a toolchain w/ threads"
> +	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_HAS_UDEV
> diff --git a/package/hidapi/hidapi.hash b/package/hidapi/hidapi.hash
> new file mode 100644
> index 0000000..ba00df2
> --- /dev/null
> +++ b/package/hidapi/hidapi.hash
> @@ -0,0 +1,2 @@
> +# Locally calculated
> +sha256 33e206f5e145fc1bc6aeb55084d71b55d686533d23ad5bb762746ceba81e728b  hidapi-d17db57b9d4354752e0af42f5f33007a42ef2906.tar.gz
> diff --git a/package/hidapi/hidapi.mk b/package/hidapi/hidapi.mk
> new file mode 100644
> index 0000000..23d5eab
> --- /dev/null
> +++ b/package/hidapi/hidapi.mk
> @@ -0,0 +1,27 @@
> +################################################################################
> +#
> +# hidapi
> +#
> +################################################################################
> +
> +# Use master version as the current stable is very old and some bugs
> +# have been fixed since then.
> +HIDAPI_VERSION = d17db57b9d4354752e0af42f5f33007a42ef2906
> +HIDAPI_SITE = $(call github,signal11,hidapi,$(HIDAPI_VERSION))
> +HIDAPI_INSTALL_STAGING = YES
> +# No configure provided, so we need to autoreconf.
> +HIDAPI_AUTORECONF = YES
> +HIDAPI_LICENSE = GPLv3, BSD-3c
> +HIDAPI_LICENSE_FILES = LICENSE.txt LICENSE-gpl3.txt LICENSE-bsd.txt
> +
> +HIDAPI_DEPENDENCIES = libusb
> +# When eudev is used as the udev provider, libgudev is automatically
> +# provided as it is part of eudev. However, when systemd is used as the
> +# udev provider, libgudev is not provided, and needs to be built
> +# separately. This is why we select the libgudev package only if systemd
> +# is used.
> +ifeq ($(BR2_PACKAGE_SYSTEMD),y)
> +HIDAPI_DEPENDENCIES += libgudev
> +endif
> +
> +$(eval $(autotools-package))

Hi Vicente,

This looks ok to me.

For embedded, it would be nice to be able to build with only one 
back-end (hidraw or libusb), but hidapi doesn't currently support 
building that way. One day I'll get there.

Thanks for doing this!

Alan.