fn build_script_local_fingerprints(
build_runner: &mut BuildRunner<'_, '_>,
unit: &Unit,
) -> (Box<dyn FnOnce(&BuildDeps, Option<&dyn Fn() -> CargoResult<String>>) -> CargoResult<Option<Vec<LocalFingerprint>>> + Send>, bool)Expand description
Get ready to compute the LocalFingerprint values
for a RunCustomBuild unit.
This function has, what’s on the surface, a seriously wonky interface.
You’ll call this function and it’ll return a closure and a boolean. The
boolean is pretty simple in that it indicates whether the unit has been
overridden via .cargo/config.toml. The closure is much more complicated.
This closure is intended to capture any local state necessary to compute
the LocalFingerprint values for this unit. It is Send and 'static to
be sent to other threads as well (such as when we’re executing build
scripts). That deduplication is the rationale for the closure at least.
The arguments to the closure are a bit weirder, though, and I’ll apologize
in advance for the weirdness too. The first argument to the closure is a
&BuildDeps. This is the parsed version of a build script, and when Cargo
starts up this is cached from previous runs of a build script. After a
build script executes the output file is reparsed and passed in here.
The second argument is the weirdest, it’s optionally a closure to
call pkg_fingerprint. The pkg_fingerprint requires access to
“source map” located in Context. That’s very non-'static and
non-Send, so it can’t be used on other threads, such as when we invoke
this after a build script has finished. The Option allows us to for sure
calculate it on the main thread at the beginning, and then swallow the bug
for now where a worker thread after a build script has finished doesn’t
have access. Ideally there would be no second argument or it would be more
“first class” and not an Option but something that can be sent between
threads. In any case, it’s a bug for now.
This isn’t the greatest of interfaces, and if there’s suggestions to improve please do so!
FIXME(#6779) - see all the words above