Meson wrap support

[libusb]

Meson wrap support

[Youw]

once its in-tree, maintenance of it would be simple enough

I'd say this statement is true for any modern build system. It is more about the fact that a developer have to remember to go into yet another build script/configuration file and get it updated, e.g. when one more source file is added, etc.
For example: aaf5f3d
There is two trivial changes to libusb/CMakeLists.txt and libusb/Makefile.am. With meson it will become 3 places. Tomorrow someone else will say that "oh, you already have 3, lets make it 4, because I like/need X<BUILD SYSTEM> better".

---

My point is: if it is possible to wrap around CMake (instead of copying it) - lets rather have a wrap.

[xclaesse]

The question here is - what does it take on HIDAPI side to make it possible?

You'll have to port its build system to meson, either in upstream repository or as a patch overlay in Meson's wrapdb.

[hanetzer]

on another note, meson also has a dist target which produces sensibly named tarballs
(hidapi-ver.tar.* instead of hidapi-hidapi-ver.tar.*).
I'm relatively skilled at writing meson buildscripts, so if you're interested in that I can whip
one up and pr it.

[Youw]

I imagine having possible "meson wrap install hidapi" would be very convenient for Meson users.
The question here is - what does it take on HIDAPI side to make it possible?

Recently we've developed a CMake build system, which happened to be slightly less trivial than I have originally imagined it would (extra complexity for usage convenience). And we're deprecating support of the Autotools in favor of CMake on this matter.

So do we need to make a whole new (Mason) build script for HIDAPI?
Because that would mean we need to support two (three as Autotools is not obsolete yet) build systems at the same time, which would be unfortunate.

Can we have Mason re-use CMake scripts for its build?

As an alternative: can we have CMake generate Mason "import files" (is that even a thing?), similarly as we generate pkg-config import files? I.e. build HIDAPI with CMake and then publish the artifacts somewhere where meson wrap ... could get it from.

[hanetzer]

meson can consume FindFoo.cmake files, I know that much, not sure about wrapdb integration. However, its a pretty simple 'scripting language' (not right term but close enough for gov't work), so once its in-tree, maintenance of it would be simple enough, unless the project decides to add some truly insane steps to the build.

[hanetzer]

My point is: if it is possible to wrap around CMake (instead of copying it) - lets rather have a wrap.

No, as far as I can see the way a wrapdb works is you have pkgname.wrap file, which defines what deps
it provides, where to get the raw source, and if pkgname isn't already meson, provide a 'patch' which
converts it over.

You can see it here https://github.com/mesonbuild/wrapdb, under the subprojects directory. If you go a directory deeper under pkgfiles you'll find the files used to create the 'patch'.

[xclaesse]

A project that uses hidapi could uses Meson's cmake module to build hidapi: https://mesonbuild.com/CMake-module.html#cmake-subprojects. But that has many limitations and bugs.

[eli-schwartz]

As an alternative: can we have CMake generate Mason "import files" (is that even a thing?), similarly as we generate pkg-config import files? I.e. build HIDAPI with CMake and then publish the artifacts somewhere where meson wrap ... could get it from.

meson natively uses pkg-config. Projects depending on hidapi do e.g. hidapi_dep = dependency('hidapi') and this will look up hidapi.pc via pkg-config.

meson wrap is an additional dependency lookup method. By passing a meson option, the build system can be told to prefer local (vendored) private versions of dependencies, which relies on having hidapi build using meson -- then hidapi would get imported into the other project and built from scratch. This has some advantages, if users might not have hidapi installed or their distro doesn't provide a new enough version. Or if they use Windows where dependency management is complicated.

[Youw]

A project that uses hidapi could uses Meson's cmake module to build hidapi

I would give it a shot.

But that has many limitations and bugs.

Let see if we hit any of those.

[Youw]

So yes, we do hit some limitation here (e.g. cannot re-use CMake alias targets), but there is a straight-forward workaround and so far I came up with this:
https://github.com/libusb/hidapi/tree/meson_support

I guess it can be greatly improved (add version info for starters), but I'd be more than happy to accept such change into master.
I also not sure how my current implementation would fit with already existing pkg-config method on linux (e.g. compatibility over target names and so on).

But other than that - I don't see any "limitations and bugs" that would make such approach unfeasible.

Thoughts?

[Youw]

@eli-schwartz your comments on https://github.com/libusb/hidapi/tree/meson_support are welcome

[Youw]

Lets make it even better: #410

[eli-schwartz]

I tried to build it, but whatever magic incantations the auto-translation attempted to do seem to have failed because the libraries don't have any source files as far as Meson is aware.

[eli-schwartz]

Update: it works successfully if I move the hidapi source tree into subprojects/hidapi_build_cmake/ rather than using that shim file which I don't quite understand the workings of.

[Youw]

move the hidapi source tree into subprojects/hidapi_build_cmake/

That shouldn't be required. Can you share failure logs when running on the original branch?

[Youw]

Ah, I see:

hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/hidapi is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/windows/hid.c is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/hidapi/hidapi.h is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/windows/hidapi_winapi.h is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/windows/hidapi_cfgmgr32.h is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/windows/hidapi_hidclass.h is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/windows/hidapi_hidpi.h is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/windows/hidapi_hidsdi.h is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| WARNING: CMake: path C:/projects/hidapi/hidapi is inside the root project but not inside the subproject.
hidapi_build_cmake| WARNING:  --> Ignoring. This can lead to build errors.
hidapi_build_cmake| CMake project Project has 2 build targets.

I haven't tried to build hidapi directly. Instead I used a different project, where hidapi is a subproject on its own - that way it works.

[Youw]

Updated the implementation.
Added CI scripts.

[Youw]

As much as will be done in scope of this repo - already done in scope of #410