libusb as a submodule along with CMakeList.txt ? #1

Closed
opened 7 months ago by ankurvdev · 7 comments

I tried contributing a CMakeList.txt for libusb
https://github.com/libusb/libusb/pull/1134
But it was rejected as the maintainers of libusb dont seem keem on adopting cmake.

Given rtl-sdr is a cmake project I think it'll be beneficial to have libusb used as a submodule with the CMakeList.txt from the above pull-request.

Currently rtl-sdr tries to use pkg-config to locate libusb libraries and headers which can be pretty inconvinient especially when dealing with android or trying to build a rtl-sdr based project (Here's mine: https://github.com/ankurvdev/libadsb)

Would it make sense to park a CMakeList.txt here that builds libusb optionally as a submodule ?

I tried contributing a CMakeList.txt for libusb https://github.com/libusb/libusb/pull/1134 But it was rejected as the maintainers of libusb dont seem keem on adopting cmake. Given rtl-sdr is a cmake project I think it'll be beneficial to have libusb used as a submodule with the CMakeList.txt from the above pull-request. Currently rtl-sdr tries to use pkg-config to locate libusb libraries and headers which can be pretty inconvinient especially when dealing with android or trying to build a rtl-sdr based project (Here's mine: https://github.com/ankurvdev/libadsb) Would it make sense to park a CMakeList.txt here that builds libusb optionally as a submodule ?
tnt was assigned by laforge 7 months ago
steve-m was assigned by laforge 7 months ago
horizon was assigned by laforge 7 months ago
Owner

Not my decision, but my opinion is no ...

Why would we :
(1) bring projects as submodules that don't need to be
(2) maintain a build infrastructure for said project

If it's a problem for Android, I suggest you try to convince google to adopt a pkg-config based dependency system instead then.

Not my decision, but my opinion is _no_ ... Why would we : (1) bring projects as submodules that don't need to be (2) maintain a build infrastructure for said project If it's a problem for Android, I suggest you try to convince google to adopt a pkg-config based dependency system instead then.
Poster

(1) bring projects as submodules that don't need to be

  • Would not require libusb to be "installed" in known locations (or hinted locations) as a pre-configure or cmake-generate step.
  • Reduces system dependencies. It'll be "optional" in case libusb couldnt be found.
  • Since libusb builds along with rtlsdr, it can easily be subsumed in a single dll/lib make it easier for further linking or loading downstream binaries.

(2) maintain a build infrastructure for said project

Totally understandable and agree its unreasonable.

> (1) bring projects as submodules that don't need to be * Would not require libusb to be "installed" in known locations (or hinted locations) as a pre-configure or cmake-generate step. * Reduces system dependencies. It'll be "optional" in case libusb couldnt be found. * Since libusb builds along with rtlsdr, it can easily be subsumed in a single dll/lib make it easier for further linking or loading downstream binaries. > (2) maintain a build infrastructure for said project Totally understandable and agree its unreasonable.
Owner

I really think this is a very android-centric point of view. rtl-sdr is developed and primarily used on regular Linux systems (or even on windows), where libusb is available as a shared library.

If Android forces everyone to re-invent the wheel and package all the libraries as part of their 'app', that's their odd choice to make.

I really think this is a very android-centric point of view. rtl-sdr is developed and primarily used on regular Linux systems (or even on windows), where libusb is available as a shared library. If Android forces everyone to re-invent the wheel and package all the libraries as part of their 'app', that's their odd choice to make.
Poster

Even on linux systems (even more on windows) its still beneficial to ship standalone-static-binaries that do not load (or find) other shared libraries.

And it can be especially useful for executing rtlsdr on SoCs where libusb isnt available as a precompiled package.
Or
on windows where the binaries are truly standalone without requiring dlls to be shipped alongside.

On Android:
I think the problem is more around cross-compilation and mixing build-systems than Android in particular.
It simply makes it harder to compile libusb which has 3 individual build system (based on your choice of platform) and use it with rtlsdr which you have the option of autotools or cmake

Even on linux systems (even more on windows) its still beneficial to ship standalone-static-binaries that do not load (or find) other shared libraries. And it can be especially useful for executing rtlsdr on SoCs where libusb isnt available as a precompiled package. Or on windows where the binaries are truly standalone without requiring dlls to be shipped alongside. On Android: I think the problem is more around cross-compilation and mixing build-systems than Android in particular. It simply makes it harder to compile libusb which has 3 individual build system (based on your choice of platform) and use it with rtlsdr which you have the option of autotools or cmake
Owner

Even on linux systems (even more on windows) its still beneficial to ship standalone-static-binaries that do not load (or find) other shared libraries.

I think this is fundamentally opposed to how Linux distributions have worked for decades. I for my part don't want 25 different versions of a library installed, but one that is maintained and works. If somebody wants to do it different, it is their choice. But then don't put the burden on the upstream authors.

> Even on linux systems (even more on windows) its still beneficial to ship standalone-static-binaries that do not load (or find) other shared libraries. I think this is fundamentally opposed to how Linux distributions have worked for decades. I for my part don't want 25 different versions of a library installed, but one that is maintained and works. If somebody wants to do it different, it is their choice. But then don't put the burden on the upstream authors.
Poster

The request is not to change but to allow.

I am definitely not proposing changing the default mode of rtlsdr's way of shipping or conforming to standard practices.

But ...

Simply allowing an alternate mode where rtlsdr can be built in true "static-library" mode
producing fully standalone executables for platforms that might not even have a packaging
or for windows that does not require accompanying libusb dlls or rtlsdr dlls

There's a rtlsdr_static target but even that links dynamically with libusb

Having libusb as a submodule allows for that possibility and downstream can decide to enable that mode when using rtlsdr itself as a submodule.

The default can remain what it is today.

The request is not to change but to allow. I am definitely not proposing changing the default mode of rtlsdr's way of shipping or conforming to standard practices. But ... Simply allowing an alternate mode where rtlsdr can be built in true "static-library" mode producing fully standalone executables for platforms that might not even have a packaging or for windows that does not require accompanying libusb dlls or rtlsdr dlls There's a rtlsdr_static target but even that links dynamically with libusb Having libusb as a submodule allows for that possibility and downstream can decide to enable that mode when using rtlsdr itself as a submodule. The default can remain what it is today.
Owner

rtl-sdr "allows" anyone to do anything with it.

--enable-static builds a static librtlsdr.a library. This is not dynamically linked against anything. You can link it statically to application code, including other statically libraries.

Your fundamental assumption is wrong: A single software/library project is NOT responsible for maintaining forks/submodules/subtrees/buildsystems for its upstream dependencies. We are not building or packaging or maintaining build scripts for libusb, glibc, or any other libraries.

Adn this is not something specific about librtlsdr, but a fundamental way how development of open source software has worked for decades.

rtl-sdr "allows" anyone to do anything with it. `--enable-static` builds a static librtlsdr.a library. This is not dynamically linked against anything. You can link it statically to application code, including other statically libraries. Your fundamental assumption is wrong: A single software/library project is *NOT* responsible for maintaining forks/submodules/subtrees/buildsystems for its upstream dependencies. We are not building or packaging or maintaining build scripts for libusb, glibc, or any other libraries. Adn this is not something specific about librtlsdr, but a fundamental way how development of open source software has worked for decades.
laforge closed this issue 7 months ago
Sign in to join this conversation.
No Label
No Milestone
No project
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sdr/rtl-sdr#1
Loading…
There is no content yet.