libusb as a submodule along with CMakeList.txt ? #1
tnt
steve-m
horizon
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 ?
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.
Totally understandable and agree its unreasonable.
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.
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
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.
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.
rtl-sdr "allows" anyone to do anything with it.
--enable-staticbuilds 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.