Reduce the need for users to write build scripts

[epage]

Like RUSTFLAGS, build scripts are an important escape hatch. Like RUSTFLAGS (#12739), we should find replacements for common uses of build scripts so people don't have to reach to this escape hatch so often

Reducing build scripts would

• Improve build times
• Reduce risk of bugs
• Reduce the dependency review audit scope

Uses of build scripts

• Version detection
  • Stabilizing Tracking issue for RFC 2523, #[cfg(accessible(::path::to::thing))] rust#64797
  • Stabilizing Tracking issue for RFC 2523, #[cfg(version(..))] rust#64796
• Making cfg values available at runtime (e.g. in --bugreport, --version, or crash reports, or for tests building examples)
  • Possibly provide cfg_value!, cfg_values!, try_cfg_value!, try_cfg_values! (see also mutually exclusive features)
• Making TARGET available at runtime (e.g. --version, building examples in tests)
• Codegen
  • using tests
  • Allow applying static code-generation to the published package (i.e. package.rs) #12552
• Catch-all: Tracking issue for RFC 2196, "metabuild: semantic build scripts for Cargo" #14903
  • Note: this would also allow consolidating the ecosystem which would help with baking-in more features to replace build scripts
  • Enable linker warnings on Windows
  • Embedded windows manifests
  • Can we use this for -sys crates?

[ChrisDenton]

I would draw a distinction between main binary build scripts (e.g. the executable or cdylib) and libraries. I think a build scripts for an executable is far more tolerable than for libraries. They're in direct control of the crate author and don't have any other users. Also a single top-level build script is going to have negligible impact on build times for all but the smallest projects.

Which is not to say reducing the need for them is not important too, just that reducing the need for library build scripts will likely have the far bigger impact.

[epage]

This is not about trying to remove all build scripts but finding patterns in the community and providing a solution to avoid writing one yourself. In some cases, this will be using an artifact dependency as your build script. This is a general solution that helps libs and bins. And the benefits extend to bins. For smaller projects it democratizes the benefits of build scripts by making it easier to discover what you can do, easier to implement, and with fewer bugs. For larger projects with multiple bins, it makes reuse easier, reduces build times, and makes it easier to audit your own code base.

Yes, libs will get more benefits as we prioritize solutions to implement but understanding and tracking the needs of bins takes little away from that but instead gives a better understanding for designing soluations.

[kamulos]

I don't know if this is important enough, but I also have a small use-case: I integrate a version string from an environment variable into my program during compile time. A natural way to do this would be the env!() macro, but this will not rebuild if the env variable changes.

So I am forced to use a build script with the cargo::rerun-if-env-changed declaration.

[bjorn3]

env!() should rebuild when the env var changes. We changed rustc to record which env vars are read using env!() into the dep info file years ago and at the same time changed cargo to rebuild crates when env vars mentioned in the dep info file changes.

[kamulos]

Oh that works! 😊 I don't know what went wrong the last time I tested it, sorry for the confusion.

[epage]

Cargo might not fully track its own env variables which would be a bug.

iirc try_env! does not report env variables for tracking, at least if they aren't there.

[weihanglo]

Cargo might not fully track its own env variables which would be a bug.

iirc try_env! does not report env variables for tracking, at least if they aren't there.

Did you mean option_env!? They're also tracked by # env-dep: comment in rustc dep-info files.