Open notdanilo opened 3 months ago
As an additional note:
I considered publishing all the generated crates from pip on crates.io, but that would pollute crates.io with lots of automatically generated code, which I believe is undesired/unnecessary.
The proposed solution above is the ideal way to avoid publishing the automatically generated crates to crates.io.
My ultimate goal is to enrich Rust's ecosystem with AI libraries from Python.
Could you clarify a little more on what you mean in the steps "generate rust crate" and "build rust crate"?
Could you clarify a little more on what you mean in the steps "generate rust crate" and "build rust crate"?
I can, but these steps aren't important to the issue.
These steps will be done with my binding generator https://github.com/sensorial-systems/ligen
It will:
I can, but these steps aren't important to the issue.
Understanding use cases is important to make sure we are solving the right problem.
This Issue seems to be suggesting a specific solution to #8709. Generally, we encourage Issues to focus on problems and discuss trade offs on alternative solutions on those issues. In that context, I would be inclined to close this in favor of #8709 with the suggestion of you posting this idea as an alternative solution.
Is there something I'm missing in that?
The ability to programmatically set dependencies in a project through build.rs is of extreme importance for codegen tools.
[dependencies]
example = { path = "path/to/example" }
The proposed solution here would make Cargo more extensible.
I will start a PR for the proposed solution soon.
I also would like to understand why not all rustc flags are supported in build.rs and config file? Why it's more limited than using RUSTFLAGS
?
I see that the current implementation has two properties in BuildOutput holding '-L' and '-l' values, respectively and thus the limitation. But why wasn't it generalized to get all flags?
I might be wrong. From my observation the cargo::rustc-flags
instruction predates 1.0 of the Rust/Cargo (see cargo#792, specifically this commit), and now there are equivalent like rustc-link-lib
and rustc-link-search
. The existence of cargo::rustc-flags
might just be a wrong abstraction slipping into 1.0.
Problem
I have a significant goal of integrating the whole pip ecosystem to Cargo only by adding:
Cargo.toml
build.rs
But this isn't allowed due to:
Proposed Solution
Allow
--extern
flag in build script.Notes
Even though I can create an external tool (like cargo-pip) to add the required flags to
RUSTFLAGS
, this would not be orthogonal. If I want to implement the same feature to a different registry besides pip (say conda), how could I mix them in the project?cargo pip build
// would make [package.metadata.pip] dependencies availablecargo conda build
// would make [package.metadata.conda] dependencies available But how to make both [package.metadata.conda] and [package.metadata.pip] available?Another important point is that the goal is to make pip dependencies seamlessly available without the need of a third-party tool. Making it possible in build.rs guarantees easy redistribution on crates.io