Closed nikkicoon closed 7 months ago
minimal example:
cargo.toml
[package]
name = "hello_world" # the name of the package
version = "0.1.0" # the current version, obeying semver
authors = ["Alice <a@example.com>", "Bob <b@example.com>"]
edition = '2021'
[dependencies]
hidapi = { version = "2.3.3", default-features = false, features = ["unix-shared-libusb"], path = "/home/nikita/src/hidapi-rs" }
[build]
rustflags = ["-Clink-args=-lhidapi-libusb"]
src/main.rs:
/****************************************************************************
Copyright (c) 2015 Osspial All Rights Reserved.
This file is part of hidapi-rs, based on hidapi_rust by Roland Ruckerbauer.
****************************************************************************/
//! This example shows the added possibility (after version 0.4.1),
//! to move devices into a function / or closure with static lifetime bounds.
extern crate hidapi;
use hidapi::{HidApi, HidDevice};
use std::rc::Rc;
fn main() {
let _dev = test_lt();
}
fn requires_static_lt_bound<F: Fn() + 'static>(f: F) {
f();
}
fn test_lt() -> Rc<HidDevice> {
let api = HidApi::new().expect("Hidapi init failed");
let mut devices = api.device_list();
let dev_info = devices
.next()
.expect("There is not a single hid device available");
let dev = Rc::new(
api.open(dev_info.vendor_id(), dev_info.product_id())
.expect("Can not open device"),
);
let dev_1 = dev.clone();
requires_static_lt_bound(move || {
println!("{:?}", dev_1.get_device_info().unwrap()); //<! Can be captured by closure with static lt
});
dev //<! Can be returned from a function, which exceeds the lifetime of the API context
}
I do not think it makes sense to merge the different unix os into one in the build script since they all seem to require different libraries / build flags. Also it will be easier to make quick fixes to one of them if they stop working because of upstream changes.
I do not think it makes sense to merge the different unix os into one in the build script since they all seem to require different libraries / build flags. Also it will be easier to make quick fixes to one of them if they stop working because of upstream changes.
From a multi-systems package manager perspective the way I've proposed makes more sense, since you will end up with oppinionated defaults otherwise which might or might not be true in different contexts (often we have to override such oppinionated defaults when we package something due to false assumptions).
Since libusb and hidraw seem to be mutually exclusive, from what I remember from updating the package many months ago, it makes sense to have it as an either/or decision supported by pkg-config. For every deriviation from this, local patches to the build process can be applied.
Sry for the late review, I forgot to actually submit it O_o
Closed because of inactivity
A minimal working example with libhidapi 0.14.0 from pkgsrc gets me as far as this (while building the example in the post below), this seems to be picking up libusb1 as well, is this intended?