Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output build plan after running custom build scripts #7068

Open
schomatis opened this issue Jun 24, 2019 · 1 comment
Open

Output build plan after running custom build scripts #7068

schomatis opened this issue Jun 24, 2019 · 1 comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Z-build-plan Nightly: --build-plan feature

Comments

@schomatis
Copy link
Contributor

Command-build A-build-plan C-feature-request

I would like to implement an extension to the --build-plan option 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-plan in 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:

    --build-plan [=STAGE]   Output the build plan in JSON (unstable) at a STAGE in the build
                            process: `init`, before compiling/running anything (default) or
                            `post-build-scripts`, after *all* the build scripts have been run
                            (and their dependencies compiled).

These are just some arbitrary names for the --help example, 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 being compiled and the target they're intended for (UnitFor.build), to keep track of which Units do we need to compile and which just generate the Invocation for (I can expand on this in a PR with actual code). In terms of the Units that represent custom build scripts (and their execution), since the proposed option targets executing them all there is no extra tracking mechanism needed.

@schomatis schomatis added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Jun 24, 2019
@matklad
Copy link
Member

matklad commented Jul 25, 2019

cc #7178, which is a similar request, but for a slightly different goal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Z-build-plan Nightly: --build-plan feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants