Add CMakeList.txt

[ankurvdev]

No description provided.

[ankurvdev]

Ported from libusb/libusb#1134

[Youw]

a general comment:

• I suggest we follow some general CMake guidelines/code-style, e.g.: UPPER_CAMEL_CASE for all variables, including user-defined;

---

At the end, I'd like us to some practices we've umplemented for HIDAPI (documented here), e.g. add_subdirectory(libusb) should be easy to do for any project (be configurable)

[Youw]

And thanks for doing this in a first place.
Since I've volountired to support this, I might as well apply some of the fixes/suggestions I've suggested myself. At least at some point.

[bansan85]

Add various comment and add support for find_package(usb-1.0) for other project.

Feel free if you have questions 😃 Thanks for your initial commit.

Once this template will be a bit stabilize, I will try to add github actions.

[bansan85]

Do you think the project name should be libusb-1.0 instead of usb-1.0 ?

[Youw]

I don't think so.
At least for one reason - there will be lots of CMake "workarounds" to make the build binary-compatible with current Autotools (and yes, I think we should make it as compatible as possible).

So if the resulting binary is libusb-1.0.so - the library/project name should be usb-1.0. That is a logical assumption in CMake ecosystem.

[ankurvdev]

There's quite a bit of comments in here :) and i'll have limited bandwidth until next week.
I do agree with most of them and it's probably good to accommodate all of them before a merge.

I'd really appreciate any contributions to the branch if anyone else has bandwidth and would like to accelerate the merge (Seems like there's a few followup that might be queued behind it)

[ankurvdev]

a general comment:

• I suggest we follow some general CMake guidelines/code-style, e.g.: UPPER_CAMEL_CASE for all variables, including user-defined;

---

At the end, I'd like us to some practices we've umplemented for HIDAPI (documented here), e.g. add_subdirectory(libusb) should be easy to do for any project (be configurable)

It's worth adding a cmake style guide here since I have my own preferences but I'll gladly follow what you'd like them to be

I tend to follow lower_case for local scoped variables and function names and UPPER_CASE for global scope variables / cached variables (I probably have violations for my own policy in this pr) but a few lines to standardize styling might help everyone.

We can probably add a comment at the top here for styling if you don't want an extra file

[Youw]

I probably have violations for my own policy

That's probably what triggered my attention the most.

We can probably add a comment at the top here for styling if you don't want an extra file

Ideally would be to introduce something like cmake-format. But for now, jsut keeping the implementation clean/consistent - worth more as far as efforts spending is conserned.

---

The most important idea is to make the usage of CMakeLists.txt as much flexible/comfortable as possible for all of: this repo developers, package managers, submodule users, etc. That's why I referenced the HIDAPI document where many such ideas already implemented and I'd like to use those here too.

As much as I can tell based on comments in this thread - we're generally on the same page.

[bansan85]

@ankurvdev

I'd really appreciate any contributions to the branch if anyone else has bandwidth and would like to accelerate the merge (Seems like there's a few followup that might be queued behind it)

It's complicated to contribute on a PR because I can't push code on it. Should I create a PR on our repo and you merge it ?

[Youw]

I'm pretty sure you can push directly into ankurvdev/libusb-cmake:master
If not - you may ask @ankurvdev to add you directly as a contributor.

Preferably to keep the entire conversation in this thread.
Unless @ankurvdev is using his master branch elsewhere, in thich case messing around with it might be inconvenient for him/her.

[ankurvdev]

Let me know if there are any permission issues. The branch should be open for any contributions.

[madwax]

Hi I might have gotten a little carried away. A Thursday night little project went south because libusbs lack of cmake support and I pulled this repo to find the "finish me" message ;) Anyway while doing other things I've updated the CMakefile per the comments. There were also a few things wrong or missing so I've sorted them out. @ankurvdev you should have a pull request on your repo if you want to take it forward.

[mcuee]

Other than the above mentioned issues, the PR already works pretty well. I tested under Windows using the following test enviroment.

1. Developer PowerShell for VS 2022, using Ninja or Visual Studio 17 2022 generator
2. Using VS2022 to open the folder, which can create configurations for different platforms like ARM64, x86, x64, etc
3. Using MinGW64 without MSYS2, using Ninja or MinGW Makefiles generator
4. Using MinGW64 with MSYS2, using Ninja or MSYS Makefiles generator

[madwax]

@mcuee About the lib name, I would say it's in fact correct, in over +20 year of coding I've never seen a Windows static lib prefixed with lib unless there is a Linux coder around ;) The lib prefix is very much a POSIX think which is why MinGW64 does it. However naming the bin is easy.

Also good spot on the test being stress by bad.

[madwax]

@ankurvdev Just a quick question, why did you put back the "" around all the paths? Did you run into a problem or was that just a style thing?

Also thanks for the if(LIBUSB_TARGETS_INCLUDE_USING_SYSTEM) It got lost

[ankurvdev]

Quotes around paths in general are needed to handle paths with spaces.

Most of source paths here don't need spaces anymore since I yanked out the SOURCE_DIR from LIBSUSB_ROOT which wasn't really needed and libusb paths themselves dont have spaces, but I also now simply consider it a style+good-practice to have all paths and single path variables be enclosed in Quotes for uniformity.
That way, variables that can have multiple paths (lists) also stand out.

[madwax]

Good point on the spaces and as its a standards thing then cool. tbh I'm working with about 4 different styles of CMake currently and was a little bit in auto mode at the time. Will keep with the ""'s

The CMAKE_CURRENT_SORUCE_DIR Is something I do because of problems with nesting CMakefiles so its a defensive thing, in this case it might be overkill.

[ankurvdev]

I'm wondering when that's useful.

I've never had to, the only place I remember using it was an add_custom_commands that did some sort of code generation etc and wanted to deal exclusively in absolute paths with Binary dir as my working dir.

I tried an uber project with libusb add_subdirectory, with both , it being an actual subdirectory and with absolute path outside the outer project (with binary_dir) and it worked.

So I figured I'll remove it and let you holler back :)

[madwax]

lol problem.
The issue is when you want to do any processing of a targets source files. For example I have functions that prettify a targets folder structure in VS and XCode, when you get the source files and they are relative then SOURCE_DIR is used to build the abs path which is a bugger as that's set to the current CMakefile. I use similar functions to create pseudo-targets for static analysis, styling etc etc.

[Youw]

I'm wondering what your thoughts are on using subtree

Haven't tried it yet, but I believe this is a perfect opportunity to do so for me. Git submodules is the default option under the tips of my fingers, but I'm in constant search of the alternatives to it.

I would say it's in fact correct, in over +20 year of coding I've never seen a Windows static lib prefixed with lib unless there is a Linux coder around

I totally get you you on this one. In fact - I usually recommend using the "default" platform-specific behavior, which is familiar to the "natives" of the platform.

But in this particular case - we're trying to mimc the current Autotools build system of libusb, so that in cases like this there is no or minimum difference in the behavior.

TL;DR: Lets set the PREFIX property for libusb target to lib unconditionally for all platforms, same way as it is done in current build system(s) for libusb.

[Youw]

Thanks for all of the updates. I'll have a chance to take a look, hopefully, later this week.

[Youw]

@Youw
I'm wondering what your thoughts are on using subtree

See my thoughts at: #3

[ankurvdev]

Ping ...
Should we merge this now ?

[Youw]

I've applied all of the fixes from my comments myself, and I think we're in a good place to have it merged.

[Youw]

Same for shared build with -D LIBUSB_BUILD_SHARED_LIBS=ON. MinGW build is correct to produce libusb-1.0.dll and libusb-1.0.dll.a. MSVC build is incorrect to produce usb-1.0.dll and usb-1.0.lib.

Fixed.