---
robots: noindex, nofollow
tags: meetings
---

# 2026-01-06

## Attendees: Eric, Arlo, Dongpo, Scott, Josh, Eh2406 (Jacob), Weihang, epage

## FCP Reminders

- [fix(timing)!: remove `--timings=<FMT>` optional format values](https://github.com/rust-lang/cargo/pull/16420#issuecomment-3676490492)
- [feat(test): Make CARGO_BIN_EXE_ available at runtime](https://github.com/rust-lang/cargo/pull/16421#issuecomment-3697188410)
- [docs(report): enhance man pages for `cargo report *`](https://github.com/rust-lang/cargo/pull/16430#issuecomment-3697735409)

## Regression affecting static-init

https://github.com/rust-lang/rust/issues/150646

The build script was checking `(feature="debug_order" || CARGO_CFG_DEBUG_ASSERTIONS)` to set a custom `cfg`. Then the code was conditional on that custom `cfg` to refer to a an optional dependency (parking_lot). The correct behavior is that it should have only been conditional on the debug_order feature.

https://github.com/rust-lang/cargo/pull/16160 added CARGO_CFG_DEBUG_ASSERTIONS to build scripts.

cfg_aliases was checking for that env var. That env var was removed in https://github.com/rust-lang/cargo/pull/7943 (1.43), and only just added back in 1.93. This uncovered a latent bug in static-init which has been fixed in 1.0.4.

Eric: Do we want to do anything about this?

Ed: This crate had a bug in it and our behavior exposes this bug and it affects other people?

Arlo: But it was a bug in the crate, right?

Ed: Options are: move forward, delay or put in a temporary hack specific for this package and range of versions?

Josh: Or conditionalize on some factor.

Weihang: Can we emit future incompat lint?

Josh: Given we're exposingh an env var in a build script, I don't know if we can

Arlo: Was this just crater or real users impacted

Eric: Hard to say, looks like justc carter for now

Jacob: Is there a new version of static-init?

Eric: Yes, it was published 8 months ago

Ed: If crater's failing that means its lockfiles are set to an older version

Josh: I'm looking at their build.rs file history

Ed: I'm looking at their reverse dependencies. They have a lot. There's usually around 18k downloads per day

Scott: Interestingly, the crater run hits this on dev-dependency (rather than the build dependency)

Arlo: I'd expect the build dependency instead

Eric: What does this crate do?

Ed: We talked about having something like rust-sec built into Cargo so we could push notifications about dependencies to people.

Josh: It sounds like cfg_aliases does something complicated. The comment from theemathas says cfg_aliases is checking the `PROFILE` environment variable as a workaround

Arlo: Did https://github.com/rust-lang/cargo/issues/5777 get fixed even though it's still open?

Josh: I think so

Weihang: We probably want to add test cases

Ed: #5777 is about affecting config files. I don't think our change affects how config files are loaded

Eric: I don't think that changed

Josh: I feel most people seem to be expecting this to work. So there'd be a real cost of deferring this across the board to hold off to handle these ranges. People assume this works so we should fix it.

Josh: If not for that, I'd say we could expose this under a new name. But it does look like a huge swath of the ecosystem is checking this under the current name.

Ed: This is the correct name for exposing the feature. I don't think we want to do it under a different name.

Josh: Agreed.

Weihang:

Ed: Nothing saw debug assertions before but build scripts can now see it. It doesn't change how manifests work now.

Eric: According to crater, ther's about 11 crates on crates.io with a lockfile within this range

Ed: We can then send 11 PRs ot update the lockfile?

Eric: There's additional about 20 git repos

Josh: Based on the previous breakage of this type (`time`), it doesn't seem to be the case that people would upgrade their packages

Josh: We could update the version and send PRs. We could decide to do nothing because we feel this is acceptable breakage. Or we could add a hack that amounts to: if you're one of these three crates, make a loud warning and tell them not to set this environment variable.

Ed: If it's only 10-30 repos, it's relatively easy to post the PRs to. It does affect people doing historical runs and seeing cargo's broken

Josh: That makes sense to me: send patches to update to 1.0.4. Focus on the published crates. And if we find the breakage is severe enough, we can decide to bump this by one version closer to the cut

Arlo: I think it's fine, especially since breakage was fixed 8 months ago

Jacob: Posting an issue might also help. Just posting them should be enough context. We told people about it, this is a tiny percentage of the community.

Weihang: We had an idea that we could have a build-script runner or wrapper. If we had that, people could remove the environment variable. Maybe we could do that for people to fix this.

Arlo: Or they could update.

Weihang: that, yes.

Ed: I did open issues for the build-dir layout crater run and all over the Christmas breaks getting notification and about 50/50 issues were closed or left open.

Eric: I feel the sentiment is we probably just want to continue and try to push up some PRs and maybe say something in the release notes?

Ed: Yes. If you have the list of repos and crates I can create issues and open PRs.

Eric: https://crater-reports.s3.amazonaws.com/beta-1.93-1/index.html just look for static-init there

Eric: I also want to talkto the Release team to check with them.

Weihang: I can update the changelog.

## static `rerun-if-changed` / `rerun-if-env-changed` in manifest

https://github.com/rust-lang/cargo/issues/6689

Weihang: A person was asking about knowing how the build dependencies in cargo.toml. They want to declare rerun-if/env/-changed in cargo.toml. I pointed out that there may be issues with dynamic dependencies. But I think it's still valuable -- worth exploring it. Maybe behind an unstable flag for static dependencies.

Weihang: A lot of other build systems want to inspect this info from the build script but they have no way to access it.

Ed: The original issue asked for being able to set these without having any build script. To work around proc macros. We should split that and fix proc macros and stabilize the features.

Ed: For the second thing, if this allows us to no longer scan the entire directory on first build because we don't know rerun-if-changed we'll get, that might be useful. But the question is how many of these are static vs. dynamic and how do we deal with both being set.

Eric: I agree with the split. I don't think proc macros are our responsibility and there's an feature for that.

Josh: +1 for splitting and that the old issue should be addressed by saying proc macros should specify which files they'll use. But for the second one, sounds they want to parse cargo.toml, extract the info and do change decection themselves. That makes sense, but it would only apply for crates that declare this explicitly in cargo.toml as opposed to the vast majority crates that don't declare `rerun-if-change` at all. That means you have to run the build script to be able to see whether the build script should be run.

Weihang: I don't think they want to skip the build script. Their build system can use this so they can see whether their cache can be applied

Josh: They want to see if they want to skip building the entire crate. I'm sympathetic to that, but I don't think that would be enough because they have to handle build scripts that don't set this and know why.

Ed: Build scripts aren't the only things where dynamic paths are added. Just compiling Rust code can add paths.

Josh: I'd bet they're just saying "does any *.rs file change"

Weihang: Other systems like bazel or nix

Josh: That makes sense. They may only need this for things outside the build directory.

Arlo: Or environment variables

Josh: I'd say nix would make sure no extra variables do

Weihang: The official rust build tool for nix patches build script. I think this person doesn't work on the nix official tool, they're working on their own.

Josh: I'd guess their intention is: if this kind of thing became more popular in the ecosystem, then our lives would be better. Would this actually have the necessary effect?

Josh: I'd love to see more bits of build scripts declaratively. It would solve the problem of crates that only do the build script to set these. And for crates that ??. And if it's inside the source directory, it's going to be it's a static path. If it's outside, it's never going to be a static path -- you'd need to detect that with pkg-config etc.

Josh: I'd ask them if this is for things outside of the src directory. If it's outside, then it shouldn't be the static path.

Ed: This will eventually require the RFC. But it will need a research on how much will the ecosystem would be able to adapt.

Jacob: Given we want move build scripts outside of build script to cargo.toml, an RFC that showe a lot of real-life builds scripts that show how to do this would be really helpful.

Ed: And it has to be a good amount of top 1k crates or a long tail of crates.

Josh: Proposed resolution: I can talk about the separate issues taht we think should be split. Broadly speaking we're in favor of declarative things, but the only things that would be able to be declared statically would be files within the source tree. We're wondering how broadly this pattern would be applicable.

Ed: Are they absolute vs. relative paths but also: are they conditionally specified?

Arlo: I've been looknig at github code search and very few are of the static path type

Weihang: Do we also want to split the env var thing into a separate change?

Arlo: They're both rerun-if-changed things so I think it could be together

Ed: I could see there being a superset of what build script is doing and us doing a subset. But that would need a sandboxed build script and I'm not sure it would be that useful to say "here's what we might look at but the build script will say waht we *will* look at"

Eric: Who would be using this? Right now we have one person doing an experiment of getting nix inside cargo.

Ed: On Zulip they're talking about this being an official part of cargo

Eric: I don't want to dismiss it though because Cargo is difficult to work with because of build scripts

Ed: We could point them to the tracking issue for remove build script issues: https://github.com/rust-lang/cargo/issues/14948

Jacob: Our inability to work in bigger build systems has been intractable. A part of me wants to say we should demand the perfet be enemy of the good. IF we can help in a small way, lets do that. But is this the right thing?

Ed: It's not clear that this proposal will actually be helpful to anyone, really

(discussion of depinfo and how many people are using `make`)

Ed: I imagine the depinfo files might be useful for things like cargo-watch

(the meeting ended here)