You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it appears that built determines the value of DEPENDENCIES by just parsing Cargo.lock and extracting the name & version of every entry. This strikes me as suboptimal, as presumably one would want the list of dependencies stored in a binary to match the actual dependencies used to build it, i.e., excluding dev dependencies, dependencies for other targets, and dependencies for inactive features.
As built currently doesn't do such filtering, I implemented it myself in my own build.rs by using cargo-metadata and traversing the "resolve" nodes; feel free to make use of this MIT-licensed code if you need it.
The text was updated successfully, but these errors were encountered:
@lukaslueg Could this be re-opened? What I'm asking for is distinctly different from just separating direct dependencies from indirect, and this issue is not resolved by the commit that resolved #49.
Currently, it appears that
built
determines the value ofDEPENDENCIES
by just parsingCargo.lock
and extracting the name & version of every entry. This strikes me as suboptimal, as presumably one would want the list of dependencies stored in a binary to match the actual dependencies used to build it, i.e., excluding dev dependencies, dependencies for other targets, and dependencies for inactive features.As
built
currently doesn't do such filtering, I implemented it myself in my ownbuild.rs
by usingcargo-metadata
and traversing the "resolve" nodes; feel free to make use of this MIT-licensed code if you need it.The text was updated successfully, but these errors were encountered: