Comments (2)
I have wondered if there would be benefits to allowing package.build
to be split out into its own target table.
For the field name, I would likely go with [whatever field is used with per-package-targets (currently forced-target
).
Do you need only the build script to be forced to a target or would doing it for the entire package work? Granted, not everyone with forced-target
might want that but I worry about a package that is meant for any target but the build script only works on one.
As for the request itself, it feels a bit odd to me and I'm hesitant. I'm not sure if its lack of knowledge or familiarity with the use case or what.
from cargo.
The crate itself happens to be built for x86_64-pc-windows-msvc as well, so building the build script and the crate for the same target would work.
I agree that restricting builds to a particular target can be problematic. However, a build script that builds for any target, but then works only on one target because it spawns a target-specific subprocess makes little difference.
from cargo.
Related Issues (20)
- Print a note when `cargo new` is editing `workspace.members` HOT 3
- multiple path dependencies with the same name confuses the resolver HOT 2
- Benches: improved user experience for adding new benchmarking files HOT 3
- Issue with the Code of Conduct in Readme.md redirecting to a `422: Unprocessable Entity` HOT 2
- profile_trim_paths::lldb_works_after_trimmed requires elevated privileges on macOS
- Cargo build giving checksum mismatch error HOT 9
- Fail early when trying to build for an unavailable target HOT 4
- cargo install probe-rs --features cli fails HOT 2
- [rustdoc] Integration test documentation build failure HOT 3
- Cargo 1.78 release date is in the future HOT 1
- Disable adding a feature when using cargo-add --optional HOT 2
- Add support for binary dependencies HOT 2
- Option to disable workspace edit feature of cargo new HOT 4
- `cargo doc` should suggest `--lib` override if documenting a crate with only `doc = false` targets HOT 2
- `include_str!` does not work in cargo script if there are dependencies HOT 1
- Potential locking issue on macOS HOT 1
- Heuristics to include Cargo.lock or not in a package are suboptimal HOT 2
- cargo test: option to run all tests under the same binary HOT 5
- `cargo install crate1 crate2 ..` updates index repeatedly for every crate in list. HOT 3
- Allow manifest dependencies of same-workspace crates to use `workspace = true` HOT 3
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 cargo.