Hi guys,
I was in the process of writing a module for finding libusb-1.0, and I hit a snag that has been a common pattern I’ve had for a while. Sometimes I have an SDK that requires a library, like libusb-1.0. I have that library on my machine, but I don’t have the dev package for it. This is common on many systems I develop on, redhat 8/9, rocky linux, and so on. Most modules will fail to find packages due to the missing headers, and it then creates a situation where a lot of workarounds need to be done, in a not so elegant way.
Before anyone asks, yes, there are several, probably 50 versions of Find//usb//.cmake that I could use, and pkg-config, and all of that. This question isn’t about libusb-1.0 so much as it displays why I’m going to ask for ideas here.
I have on my machine
usr/lib64/libusb-1.0.so.0
/usr/lib64/libusb-1.0.so.0.2.0
and a standard call wont get it.
find_library(LIBUSB_LIBRARY
NAMES ${_LIBUSB_LIB_NAMES}
HINTS ${_LIBUSB_SEARCH_HINTS}
PATHS ${_LIBUSB_SEARCH_PATHS}
PATH_SUFFIXES
lib
lib64
lib32
lib/x86_64-linux-gnu
lib/i386-linux-gnu
lib/arm-linux-gnueabihf
lib/aarch64-linux-gnu
DOC “libusb library”
)
Due to the suffix on the library. I see that i might be able to append and then remove from the list CMAKE_FIND_LIBRARY_SUFFIXES, but that doesn’t feel particularly clean. I could call find_file and get it that way, but that’s not really in the spirit of finding a library either.
Would it be possible to extend find_library just a bit so that it can take a variable like NAME_SUFFIXES so that a user could specify something like
NAME_SUFFIXES ““ “.0” “.1”
The computed name might then become usb-1.0<.so><.0>
or similar? That would give a lot of freedom in finding more libraries, without all the extra workaround that gives area for breakage.
I’m open to other ideas too, if I’m completely being oblivious to something.
Thanks!
Kyle B