Comments (7)
Initial attempt https://github.com/karalabe/gousb . I did rewrite the import paths to allow easier development, testing, use for myself. If you chose to accept the changes upstream, obviously I'll change them back.
It is covered by CI on linux, macos and windows. It seems to build correctly on android. On ios there's some strange error with a missing header file from the IOKit framework, I need to check whether it's my borked OS or whether it's a genuine issue.
from gousb.
I'm not sure about this approach - I understand it assumes linking libusb statically into the output binary.
On one hand I understand the motivation between having a hermetic deployment that is buildable and deployable without any dependencies.
On the other hand, typical non-container deployment would explicitly rely on shared libraries to pick up bugfixes and improvements in all installed apps without the need to recompile. I believe this is the more common scenario.
Admittedly, I don't know much about how vendoring of non-Go libraries works here, so perhaps I'm missing something? Is there a way to use the included libusb in a dynamic fashion and only if there's no system-wide libusb?
from gousb.
I agree that this is a rather philosophical question, but to highlight the main problem with relying on pre-existing dependencies, just look at the README's Windows section: https://github.com/kylelemons/gousb#installation-on-windows
On Linux and arguably OSX, dependency management is more or less clean, and if something's missing, it's easy to install. However there might be other platforms Windows, Android, iOS, etc where it may be hard to impossible to install dependencies.
My particular use case is a crypto currency hardware wallet. There I cannot really expect average Joe to know, care or even want to install libusb, or heavens forbid compile it himself.
Go's major advantage from my perspective over other languages are that the binaries are portable between machines. I can have a messy development machine and/or build server that assembles everything, but after that it's a single binary that can be moved around. That is imho a huge asset that should not be taken away from people lightly.
Of course I do understand the other perspective, that dynamic linking can get you bugfixes, however this still depends on the factors that the new version is compatible with the old one, or that the library is still available on your newer OS distribution years later (e.g. Ubuntu dropped the JSONCPP (or something) library, and it's also unavailable on other distros, meaning that any code relying on that breaks, and there's no easy way to fix it). A hermetic binary is much better from this perspective that you have much harder guarantees that it works and works the same way as always (which could mean the same buggy way).
If you don't feel confident enough about such a change, we could also perhaps ask for some input from main contributors to Go itself. I myself am surely not the best person to make such a decision, just trying to describe why it would be more that useful for the use cases I'm concerned with. Perhaps @davecheney @rakyll @bradfitz could share their thoughts in a sentence or two?
from gousb.
To be clear: I don't think anyone is taking away the option to compile statically. One of the benefits of using pkgconfig is that in your build environment you can configure pkgconfig to provide flags for linking whatever libraries statically.
Another way is to pass the extra "-static" flag to linker ldflags, like this:
go build -ldflags="-extldflags=-static" ...
That will produce a binary with no runtime dependencies on libusb. I've confirmed that now on a Windows VM, just to be sure.
Overall I believe we're looking at two different scenarios:
-
developer. If you're building packages, you're a developer. Managing dependencies and picking options for how you want to build your projects is expected. Setting up libusb for building gousb is part of the job.
-
user or deployment. You want something that works and "building" is not a thing. It doesn't matter whether you're preparing a package for a server, an android app, desktop app, whatever. You expect the developer to deal with the complicated details and in the end you want something that is common for your platform.
For Linux that might mean a package for your distro, or a static binary to use. For windows that means typically either a standalone binary, or .dll packaged together with the binary. Perhaps wrapped in an installer.
"How" is really irrelevant to the user here and is only interesting to the developer that needs to prepare the deployment.
This is the case I think of when you say "average Joe".
I don't think the dependencies setup in gousb, which itself is a library, is affecting your users. It might be affecting your developer setup, but not as much as I think you're saying it does.
from gousb.
Requiring custom build flags will make any package using gousb non go gettable any more though.
from gousb.
In your approach you move the platform features configuration from libusb configure into static CFLAGS parts of usb.go. That's what aclocal/autoconf/automake/configure in libusb is for and you're setting yourself up for build problems on platforms that you haven't tested on.
Embedding libusb while requiring the entire autoconf dance in integrated libusb makes the package no longer go-gettable, which defeats the point as I understand it.
I don't see any better solutions. Dependence on non-Go libraries in go is not going to fit entirely under the "go get" umbrella and I think that's acceptable.
I think I understand your arguments, and I disagree that it would be a good decision for gousb in general.
from gousb.
I don't agree, but alas that's what forks are for :)
from gousb.
Related Issues (18)
- Using with Homebrew's libusb HOT 12
- GPL use of xbox.go HOT 1
- Paths are hardcoded in usb.go HOT 1
- Writing or copying files to USB devices HOT 5
- Partial data on timeouts HOT 7
- Any examples for writing to devices? HOT 3
- read systematic timeouts HOT 9
- Race condition when closing Context
- Link in short description returns a 404 HOT 1
- Flexible array members (in libusb.h) not supported on arm-linux-gnueabihf (Raspberry Pi 3) with gcc 5.4 HOT 21
- xfer_callback panic HOT 5
- Appveyor build HOT 14
- Deprecation notice HOT 1
- Endpoint problem HOT 11
- How to link libusb on mac if I want to release a program without "brew install libusb" HOT 1
- Segfault if more than one usb context created HOT 8
- libusbx HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gousb.