WIP: Add extra check for libusb-1.0 #125

There is no content yet.

[ 12%] Building CXX object kcontrol/input/CMakeFiles/kcm_input-module.dir/mouse.cpp.o
In file included from /usr/src/qi/build/tdebase-trinity-14.0.7/kcontrol/input/mouse.h:49,
                 from /usr/src/qi/build/tdebase-trinity-14.0.7/kcontrol/input/mouse.cpp:70:
/usr/src/qi/build/tdebase-trinity-14.0.7/kcontrol/input/logitechmouse.h:37:10: fatal error: usb.h: No such file or directory
   37 | #include <usb.h>
      |          ^~~~~~~
compilation terminated.
make[2]: *** [kcontrol/input/CMakeFiles/kcm_input-module.dir/build.make:86: kcontrol/input/CMakeFiles/kcm_input-module.dir/mouse.cpp.o] Error 1
make[2]: Leaving directory '/usr/src/qi/build/tdebase-trinity-14.0.7/BUILD'
make[1]: *** [CMakeFiles/Makefile2:16426: kcontrol/input/CMakeFiles/kcm_input-module.dir/all] Error 2
make[1]: Leaving directory '/usr/src/qi/build/tdebase-trinity-14.0.7/BUILD'
make: *** [Makefile:130: all] Error 2

So I will add some summary here, so someone who not knows about the IRC discussions is knowing the background:

The problem has shown when @selk tried to build KControl with libusb support.
That is needed for some logitech mouse features.
His Distribution isn't offering some libusb.pc, but instead some libusb-1.0.pc.
It showed that on Gentoo it is the same way and it is just offering libusb-1.0.pc.
It showed that libusb.pc was used in ancient libusb-0.x releases.
In fact libusb-1.0.pc is the default now with recent libusb-1.x releases anyway.
Also I discovered the CMake check for that will always pass, at least in Gentoo for me, so it might be bugged?
It showed that just checking for the right libusb-1.0.pc isn't the only fix needed, because usb.h isn't anymore with libusb-1.x but was in libusb-0.x but libusb-1.x just offers libusb.h in some includes subfolder.
But it seems FreeBSD libusb-2.x is still using usb.h.

So the PR is about finding some concept/fix to make all happy. 😄

References:

EDIT: After learning more about CMake and finding out, that there are at least another broken libusb check, I would suggest that this function should be added to the common used CMake tests, so they are easy to keep up to date.

Question: the PR is marked WIP. Is more work planned on this or do we need more testing in freebsd for example?

@MicheleC, this commit does nothing good so far, because you will end up with some FTBFS. So there is more work needed and testing/research too. In *BSD it seems to work right now the way it was, because there was just a fix around some months ago.

ok, thanks Chris

I came up with something like this:

if( WITH_LIBUSB )
if( ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD" )
    pkg_search_module( LIBUSB libusb-2.0 libusb-0.1 )
 else()
    pkg_search_module( LIBUSB libusb libusb-1.0 )
endif()

if( LIBUSB_FOUND )
    set( HAVE_LIBUSB 1 CACHE INTERNAL "" FORCE )
else()
...

but this solution does not get on Slavek's fancies.
Without testing anything but having a quick thought on the topic, he's more geared towards something like:

 - pkg_search_module( LIBUSB libusb libusb-2.0 )
 + pkg_search_module( LIBUSB libusb libusb-0.1 )

Furthermore I don't understand why the concern for libusb-1.0 since there is no <usb.h> header anymore in that library, it has been replaced with <libusb.h> if I'm not mistaken.

One can note that on Linux, libusb-0.x and libusb-1.x can be installed at the same time since they aren't conflicting to each other ; for instance Slackware is providing libusb-0.1.5 under the package "libusb-compat".

API of libusb-0.1 and libusb-1.0 and libusb-2.0 are not compatible
libusb-compat provides libusb-0.1 compatible API over libusb-1.0
on FreeBSD (libusb-2.0) also provide libusb-0.1 and libusb-1.0 compatible API
kcontrol/input only support libusb-0.1 API

so just allowing libusb-1.0 for WITH_LIBUSB introduce such build errors.

Install libusb-0.1 or libusb-compat package to build current source tree.

or

Additionally detect libusb-1.0 and define other than HAVE_LIBUSB something like HAVE_LIBUSB1,
then implement libusb-1.0 support codes to kcontrol/input.

kcontrol/usbview should use libusb too.

API of libusb-0.1 and libusb-1.0 and libusb-2.0 are not compatible

libusb-compat provides libusb-0.1 compatible API over libusb-1.0

Right. libusb-0.1 is legacy, while libusb-compat is a compatible API over libusb-1.0...

on FreeBSD (libusb-2.0) also provide libusb-0.1 and libusb-1.0 compatible API

kcontrol/input only support libusb-0.1 API

so just allowing libusb-1.0 for WITH_LIBUSB introduce such build errors.

Install libusb-0.1 or libusb-compat package to build current source tree.

or

Additionally detect libusb-1.0 and define other than HAVE_LIBUSB something like HAVE_LIBUSB1,
then implement libusb-1.0 support codes to kcontrol/input.

If FreeBSD provides libusb-0.1 (legacy) and libusb-compat, it would be better to detect "libusb-1.0" due that "libusb-compat" requires the installation or the presence of "libusb-1.0", according to the source.

So it can be something like "libusb-2.0" for FreeBSD or fall in "libusb-1.0" directly. I guess

Update:

Adding "libusb-1.0.24" and "libusb-compat-0.1.7" allows tdebase to be built with -DWITH_LIBUSB=ON...

Update:

Adding "libusb-1.0.24" and "libusb-compat-0.1.7" allows tdebase to be built with -DWITH_LIBUSB=ON...

So is this issue still valid?

Hi @MicheleC !

Yes, this issue is still valid, is what @obache says above.

"libusb-compat" contains libusb.pc, so extra check is not required.
"libusb-1.0" should be installed as a dependency of "libusb-compat",
and not be used directly here.

"libusb-2.0 on FreeBSD" is special, "usb.h" on FreeBSD is just for libusb-0.1 API compatible,
should not be recognized as a part of libusb-2.0 API.
"libusb-2.0" is only on FreeBSD and it always contains libusb-0.1 API (libusb-0.1.pc)
pkg_search_module( LIBUSB libusb libusb-0.1 ) may be suitable.

I think that WIP parts should be libusb 1.0 API support codes if it is allowed and not want to install packages seemed obsoleted.

ok, thanks both for the feedback. Anyone working on what is left to do before we can remove the WIP?