Denys Zariaiev denzp Berlin, Germany

denzp/cargo-wharf 99

Cacheable and efficient Docker images builder for Rust

denzp/rust-ptx-builder 39

Convenient `` helper for NVPTX crates

denzp/rust-ptx-linker 35

The missing puzzle piece for NVPTX experience with Rust

denzp/rust-inline-cuda-tutorial 15

Let's jump into CUDA development with Rust

denzp/rust-buildkit 8

BuildKit integration for Rust

denzp/rust-ptx-support 8

Experiments with achieving better ergonomics in Rust CUDA workflow

denzp/node-relations 3

Entity relationship, role, and permissions API for Node.js

denzp/current 1

CUDA high-level Rust framework

denzp/buildkit 0

concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit

denzp/cargo 0

The Rust package manager

issue commentdenzp/rust-ptx-builder

Impossible to publish a crate using this to

Hi, thanks for checking out the project!

Could you please explain a little in details your use case and where is that path dependency?

Technically, there is no such requirement coming from this crate. It should be possible to create either a binary or library crate that contains both device and host code. With this approach, there is no need to depend on any other local crates via a path. As a bonus, you can still publish device-only crates, that would not even have a dependency on ptx-builder and would be treated any other crate on


comment created time in 2 months