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
• cfg_aliases
  • see also Reduce the need for users to write build scripts #14948 (comment))
  • see also RFC: naming groups of configuration with cfg_alias rfcs#3804
• Feature warnings (deprecations, a feature being "disabled" due to a platform or another feature, etc)
  • see also RFC: Cargo feature deprecation rfcs#3486
• 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 (Make it easier to embed a windows manifest for long paths #16328)
  • Can we use this for -sys crates / FFI?

[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.

[nicoburns]

Can we add "cfg aliases" to this list (i.e. what is implemented using a build script by the https://docs.rs/cfg_aliases/latest/cfg_aliases/ crate)?

Winit is a prominent crate that depends on this cfg_aliases, and from a Dioxus/Blitz perspective I understand why they've done this. We support 6 platforms (windows/macos/linux/ios/android/web) and try to provide fine(ish)-grained feature flagging for each supported feature to allow users to optimise build times and binary sizes. This leads to cfg expressions that spread to 6 lines or more.

Use cases where this is commonly comes up are where there is functionality that works on N of M platforms (e.g. 3 of 6), that you also want to be controllable with a feature flag (users may or may not want the function), and that you want to be disabled on platforms where it doesn't work even when the feature is enabled (as otherwise it becomes burdensome for users to set platform-specific features (where this is even possible)).

To give an entirely concrete example. In blitz-shell we use muda for implementing system menus on windows/macos/linux(desktop), but this functionality isn't available and doesn't make sense on android/ios/web. We also wish to make it optional on platforms that do support it. So we need a feature flag AND platform-specific cfgs, which ends up being a lot of boilerplate.

It would be nice if we could define aliases (either in lib.rs or Cargo.toml) and then use a simple #[cfg(menu)].

[epage]

@nicoburns I've added cfg_aliases. An intermediate solution would be to stabilize metadeps and then you could declare cfg_aliases as one of your build scripts, passing parameters to it. This would mean only one build script bin related to cfg_alises would be built across your entire dependency tree or need to be audited.

[epage]

I feel like the use cases given might have some overlap with global, mutually exclusive features and I wonder if there is a way to fit a higher level construct into that.

[heaths]

Another use case we have is to record the rustc version used to compile with our library that we telemeter, if enabled. Currently I don't see anything obvious recorded in ELF or PE/COFF executables that record the rustc version used - perhaps it's in the debug info, but that may not have been deployed - but perhaps making some basic info available in header or section data - perhaps the debug section - could be exposed at runtime. I admit I don't know much about ELF - Windows had been my primary dev env for decades - but looking at a release-build from rustc, it does look like GCC is recording quite a bit of build/version information so maybe it's warranted to add some rustc info? MSVC (and apparently clang on Windows now) also stores some linker info in the PE/COFF as well.

I mean, there's other ways as well like linking in function to get info, but stamping this in the executable might be useful to external tools as well. Just some thoughts.