add meson #426

2022-06-11T22:28:55-05:00

neheb commented

2022-06-11 22:28:55 -05:00

(Migrated from github.com)

Helps to avoid iconv problems that the CMake build has.

Signed-off-by: Rosen Penev rosenp@gmail.com

Helps to avoid iconv problems that the CMake build has. Signed-off-by: Rosen Penev <rosenp@gmail.com>

👍 1

eli-schwartz (Migrated from github.com) requested changes

2022-06-12 01:26:35 -05:00

meson.build

					
				@ -0,0 +1,47 @@

				project('hidapi', 'c', version: files('VERSION'),meson_version: '>=0.60')

  version : files('VERSION'),

The other build systems read the version from here, might as well do it for Meson too. ;)

```suggestion version : files('VERSION'), ``` The other build systems read the version from here, might as well do it for Meson too. ;)

meson.build

					
				@ -0,0 +13,4 @@

				if libusb_dep.found() and iconv_dep.found()

				  libhidapi = library('hidapi-libusb',

				    'libusb/hid.c',

				    dependencies: [ iconv_dep, libusb_dep ],

This should depend on threads, I think.

Also, it is only called "-libusb" on linux.

And on Windows or macOS it uses the sources from windows/ or mac/ instead. See e.g. github.com/libusb/hidapi@59e84ca74f/Makefile.am (L18-L40)

This should depend on threads, I think. Also, it is only called "-libusb" on linux. And on Windows or macOS it uses the sources from windows/ or mac/ instead. See e.g. https://github.com/libusb/hidapi/blob/59e84ca74fae41a43f8ff3ea96b4f956c79c69b4/Makefile.am#L18-L40

meson.build

					
				@ -0,0 +29,4 @@

				if udev_dep.found() and host_machine.system() == 'linux'

				  hidraw_lib = library('hidapi-hidraw',

				    'linux/hid.c',

I think this is only built on Linux.

neheb (Migrated from github.com) reviewed

2022-06-12 02:24:04 -05:00

meson.build

					
				@ -0,0 +13,4 @@

				if libusb_dep.found() and iconv_dep.found()

				  libhidapi = library('hidapi-libusb',

				    'libusb/hid.c',

				    dependencies: [ iconv_dep, libusb_dep ],

threads probably implicitly gets included with libusb.

edit: as for the others, I'd probably have to use wrapdb's CI for that. Need libusb first though.

threads probably implicitly gets included with libusb. edit: as for the others, I'd probably have to use wrapdb's CI for that. Need libusb first though.

eli-schwartz (Migrated from github.com) reviewed

2022-06-12 02:27:10 -05:00

meson.build

					
				@ -0,0 +1,47 @@

				project('hidapi', 'c', version: files('VERSION'),meson_version: '>=0.60')

This works for project, specifically.

For libraries just use meson.project_version()...

This works for project, specifically. For libraries just use meson.project_version()...

JoergAtGithub (Migrated from github.com) reviewed

2022-06-12 03:20:11 -05:00

meson_options.txt

					
				@ -0,0 +1,7 @@

				option('hidraw', type : 'feature',

				  description : 'Build hidraw. Requires udev.',

description : 'Build hidapi with hidraw backend. Requires udev.',

```suggestion description : 'Build hidapi with hidraw backend. Requires udev.', ```

JoergAtGithub (Migrated from github.com) reviewed

2022-06-12 03:20:35 -05:00

meson_options.txt

					
				@ -0,0 +3,4 @@

				)

				option('libusb', type : 'feature',

				  description : 'Build hidapi. Requires libusb.',

description : 'Build hidapi with libusb backend. Requires libusb.',

```suggestion description : 'Build hidapi with libusb backend. Requires libusb.', ```

Youw commented

2022-06-12 10:39:31 -05:00

(Migrated from github.com)

What does it solve compared to #410?

avoid iconv problems that the CMake build has

There is 0 known issues related to iconv: https://github.com/libusb/hidapi/issues?q=is%3Aissue+is%3Aopen+iconv

Can you elaborate?

What does it solve compared to #410? > avoid iconv problems that the CMake build has There is 0 known issues related to `iconv`: https://github.com/libusb/hidapi/issues?q=is%3Aissue+is%3Aopen+iconv Can you elaborate?

neheb commented

2022-06-12 22:10:31 -05:00

(Migrated from github.com)

What does it solve compared to #410?

avoid iconv problems that the CMake build has

There is 0 known issues related to iconv: https://github.com/libusb/hidapi/issues?q=is%3Aissue+is%3Aopen+iconv

Can you elaborate?

didn't know there was another PR.

Anyway, issue is that when both external and internal iconv implementations exist, CMake's find_package(Iconv) fails to find iconv and terminates the build. More info here:

https://github.com/openwrt/packages/actions/runs/2477509891
https://github.com/openwrt/packages/pull/18738

solved by using dependency('iconv') which just works.

> What does it solve compared to #410? > > > avoid iconv problems that the CMake build has > > There is 0 known issues related to `iconv`: https://github.com/libusb/hidapi/issues?q=is%3Aissue+is%3Aopen+iconv > > Can you elaborate? didn't know there was another PR. Anyway, issue is that when both external and internal iconv implementations exist, CMake's find_package(Iconv) fails to find iconv and terminates the build. More info here: https://github.com/openwrt/packages/actions/runs/2477509891 https://github.com/openwrt/packages/pull/18738 solved by using dependency('iconv') which just works.

Youw commented

2022-06-13 04:04:24 -05:00

(Migrated from github.com)

I'm pretty sure, we can find a solution to CMake's find_package(Iconv).

I do not support having yet another alternative build system for HIDAPI when it can be avoided - you'd have to duplicate the entire build logic we already have in CMake.
Lets focuse on #410 and #429 instead.

I'm pretty sure, we can find a solution to CMake's `find_package(Iconv)`. --- I do not support having yet another alternative build system for HIDAPI when it can be avoided - you'd have to duplicate the entire build logic we already have in CMake. Lets focuse on #410 and #429 instead.