WIP: Add extra check for libusb-1.0 #125

Open
selk wants to merge 1 commits from feat/pkg-config into master
selk commented 2 years ago
Collaborator
There is no content yet.
Poster
Collaborator
[ 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
``` [ 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 ```
selk changed title from Add extra check for libusb-1.0 to WIP: Add extra check for libusb-1.0 2 years ago
selk added the
PR/wip
label 2 years ago
Collaborator

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.

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. :smile: References: * https://github.com/libusb/libusb * https://github.com/freebsd/freebsd/tree/master/lib/libusb 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.
Owner

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

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

@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.

@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.
Owner

ok, thanks Chris

ok, thanks Chris
Collaborator

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".

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".
Collaborator
  • 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.

* 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.
Collaborator

kcontrol/usbview should use libusb too.

kcontrol/usbview should use libusb too.
selk commented 4 days ago
Poster
Collaborator
  • 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

> * 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
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.