5

I'm trying to build logger1, which collects data from a Kinect for off-line SLAM by ElasticFusion. I'm building on Windows. I'm trying to build for x64 with VS10 (I have VS12 as well but some of the dependencies come pre-configured to VS10 so to keep it simple I'm using that.) I'm using CMake 3.9.0.

I have ironed out most of the dependencies, but libusb is giving me trouble.

I get the following output from CMake:

...
Checking for module 'libusb-1.0'
  No package 'libusb-1.0' found
CMake Error at C:/Program Files/CMake/share/cmake-3.9/Modules/FindPkgConfig.cmake:412 (message):
  A required package was not found
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.9/Modules/FindPkgConfig.cmake:588 (_pkg_check_modules_internal)
  CMakeLists.txt:12 (pkg_check_modules)

Normally at this point the CMake GUI would show some new config variables in red for include and library paths, with some non-functional default value such as ZLIB_INCLUDE_DIR-NOTFOUND which I would then have to change to the actual paths and re-run the Configure.

However, in the case of libusb-1.0, I am not given any new config variables in the GUI. I have the Advanced checkbox ticked and the needed variables still don't show.

I have downloaded a pre-built libusb-1.0.21, but CMake inevitably can't find it; this is not *nix where library paths are well-defined. I have my own directory structure on a file server for these sorts of things, so CMake absolutely won't be able to find things unless it asks me where they are, which it is not doing in this case.

In poking around a bit, I found some references in Logger1's CMakeLists.txt, as follows:

find_package(PkgConfig)
pkg_check_modules(libusb-1.0 REQUIRED libusb-1.0)

...

target_link_libraries(Logger
                      ...other libraries...
                      ${libusb-1.0_LIBRARIES})

So, it mentions that it needs libusb, but not how to find it.

There is also mention of libusb in the CMakeCache.txt file which CMake created. That file shows a number of config variables that look relevant but which are marked INTERNAL, explaining why I didn't see them in the GUI. The values of all of these were empty except for __pkg_config_checked_libusb-1.0.

I tried to set these where it was reasonably obvious, as follows:

__pkg_config_checked_libusb-1.0:INTERNAL=1
libusb-1.0_CFLAGS:INTERNAL=
libusb-1.0_CFLAGS_I:INTERNAL=
libusb-1.0_CFLAGS_OTHER:INTERNAL=
libusb-1.0_FOUND:INTERNAL=
libusb-1.0_INCLUDEDIR:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/include/libusb-1.0
libusb-1.0_LIBDIR:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/MS64/dll
libusb-1.0_LIBS:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/MS64/dll/libusb-1.0.lib
libusb-1.0_LIBS_L:INTERNAL=
libusb-1.0_LIBS_OTHER:INTERNAL=
libusb-1.0_LIBS_PATHS:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/MS64/dll
libusb-1.0_PREFIX:INTERNAL=
libusb-1.0_STATIC_CFLAGS:INTERNAL=
libusb-1.0_STATIC_CFLAGS_I:INTERNAL=
libusb-1.0_STATIC_CFLAGS_OTHER:INTERNAL=
libusb-1.0_STATIC_LIBDIR:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/MS64/static
libusb-1.0_STATIC_LIBS:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/MS64/static/libusb-1.0.lib
libusb-1.0_STATIC_LIBS_L:INTERNAL=
libusb-1.0_STATIC_LIBS_OTHER:INTERNAL=
libusb-1.0_STATIC_LIBS_PATHS:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/MS64/static
libusb-1.0_VERSION:INTERNAL=
libusb-1.0_libusb-1.0_INCLUDEDIR:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/include/libusb-1.0
libusb-1.0_libusb-1.0_LIBDIR:INTERNAL=N:/3p-build/libusb/1.0.21/prebuilt/MS64/static
libusb-1.0_libusb-1.0_PREFIX:INTERNAL=
libusb-1.0_libusb-1.0_VERSION:INTERNAL=

I then got back into CMake and pressed Configure, only to have it delete everything I put in CMakeCache.txt and then complain that it can't find the library (duh.)

I don't and have never used CMake in my own projects, so whatever is wrong is way outside my limited familiarity.

How can I get CMake to recognize the libusb files I have?

Kevin
  • 1,179
  • 7
  • 18
  • https://cmake.org/cmake/help/v3.9/module/FindPkgConfig.html – arrowd Jul 30 '17 at 07:40
  • 1
    Setting *CMAKE_PREFIX_PATH* variable works even on `pkg-config` utility, see [that answer](https://stackoverflow.com/questions/34795816/hinting-findname-cmake-files-with-a-custom-directory/34797156#34797156). However, you need `.pc` file which describes your library. – Tsyvarev Jul 30 '17 at 17:26
  • Possible duplicate of [How to Link a third Party Library (LibUSB) in CMake](https://stackoverflow.com/questions/34995936/how-to-link-a-third-party-library-libusb-in-cmake) – usr1234567 Jul 30 '17 at 21:55
  • @usr1234567 I saw that Qn before posting, but it's a different scenario: creating a CMake script to use the library in its standard directory on Linux, whereas I'm dealing with an existing CMake script that it seems uses a different approach (`pkg_check_modules`) and need it to find the library in a non-standard directory on Windows. Perhaps I just don't know CMake well enough but it didn't seem to be the same problem. – Kevin Jul 31 '17 at 08:40
  • @Tsyvarev Thank you for the tip, that seems to be relevant, but unfortunately there is no `.pc` file either in the pre-compiled distribution for Windows or in the outputs of running the VS10 project in the source distribution. There is a `.pc.in` file, but it looks like it is only processed by the GNU tool chain, which I'm not using. I'm going to try editing that to a `.pc` file by hand, though I don't know for sure what all the variables mean, so there's going to be some trial and error. – Kevin Jul 31 '17 at 08:41
  • 2
    Without `.pc` file `pkg_check_modules()` will not work. The simples way would be to replace call to `pkg_check_module()` with direct setting of `libusb-1.0_LIBRARIES` variable to appropriate value. In that case, line `find_package(PkgConfig)` isn't needed. – Tsyvarev Jul 31 '17 at 09:04
  • @Tsyvarev Thank you, that worked. If you want, you can use that for the answer and I'll mark it accepted. – Kevin Aug 09 '17 at 03:40

1 Answers1

2

you can do -

find_package(PkgConfig REQUIRED)
    pkg_check_modules(libusb REQUIRED libusb-1.0)
  • 1
    While this piece of code may provide a solution to the question, it's better to add context as to why/how it works. This can help future users learn and eventually apply that knowledge to their own code. You are also likely to have positive feedback/upvotes from users, when the code is explained. – Amit Verma Mar 02 '21 at 05:58