I discovered some strangeness associated with non-top-level build scripts, and I'm trying to figure out how it's supposed to work, and whether this is a bug in Cargo.
The internationalization crate, which I was trying to use unmodified, runs a build script that creates some macros. The macros are based on language files, which it looks for on a path relative to PWD. This yields some very strange results, including non-repeateable builds.
The Cargo documentation says "The directory containing the manifest for the package being built (the package containing the build script). Also note that this is the value of the current working directory of the build script when it starts." This is not quite right. What seems to happen is that, starting from a clean state (cargo clean), PWD (and, I think, CARGO_MANIFEST_DIR) are set to the top-level manifest directory where the top-level Cargo.toml file lives. But on later builds, PWD can point to some place in the "target" directories. I've captured the "output" file generated by the build script and can see this. I've had a project where "cargo clean" has to be run between generating debug and release builds. This seems wrong.
How it should work isn't clear. When a dependent crate is being built, its Cargo.toml file is somewhere in the files Cargo has downloaded, and PWD ought to point there. But it doesn't, at least not consistently.
Build scripts don't get an environment variable that gives the location of the top-level build directory, although Cargo knows that and targets are relative to it. Is that by intent, or an omission? Having a dependent crate depend on an externally provided file is useful. It's fairly common to want to reference a file that is parsed and used to drive code generation. The code generator is usually in a dependent crate. Was there a decision that was a bad thing? Documentation seems to be silent on this.
The motivation for this macro approach to internationalization, by the way, is egui, an immediate mode GUI system. Values of type "&str" are read on every graphics frame, so you don't want to be doing a lookup. So the run time internationalization packages are too slow for looking up all the menu items.
So, is this is a Cargo bug, a Cargo documentation error, or bad design of internationalization?
(Ubuntu 20.04 LTS, rustc 1.61.0)