-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Output build plan after running custom build scripts #7068
Copy link
Copy link
Closed
Labels
C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-triageStatus: This issue is waiting on initial triage.Status: This issue is waiting on initial triage.Z-build-planNightly: --build-plan featureNightly: --build-plan feature
Metadata
Metadata
Assignees
Labels
C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-triageStatus: This issue is waiting on initial triage.Status: This issue is waiting on initial triage.Z-build-planNightly: --build-plan featureNightly: --build-plan feature
Type
Fields
Give feedbackNo fields configured for issues without a type.
Command-buildA-build-planC-feature-requestI would like to implement an extension to the
--build-planoption to generate a build plan only after running all the custom build scripts. I'm opening this issue to get some feedback from the Cargo team and to check if this would be an acceptable change.This would extend
--build-planin a backwards-compatible way so its default behavior would still be the current implementation of generating the build plan before compiling/running anything. The extended option could look something like:These are just some arbitrary names for the
--helpexample, I would actually need some help coming up with more suitable terms that reflect the different stages in the build process.The motivation is to get a snapshot that is more accurate in terms of the modifications the custom build scripts can have over the general build process (at the cost of consuming those away from the build plan) to focus more on the intermediate artifacts that actually get linked into the final binary/library rather than on the "auxiliary" ones used only for the purposes of the custom build scripts, that won't be reflected in the final build other than for its intended side effects.
I've already been experimenting with a possible implementation and the biggest change in the current architecture would be a closer link between the
Units beingcompiled and the target they're intended for (UnitFor.build), to keep track of whichUnits do we need to compile and which just generate theInvocationfor (I can expand on this in a PR with actual code). In terms of theUnits that represent custom build scripts (and their execution), since the proposed option targets executing them all there is no extra tracking mechanism needed.