Absolute CARGO_MAKE_WORKING_DIRECTORY?

[DianaNites]

Problem Description

I'm working on an embedded project and want to use the Rust script runner after building, but unfortunately i have my embedded target set as the default in .cargo/config, which cargo sees when invoking cargo-script, causing that to fail.

That can be trivially worked around by simply changing the working directory of the rust code task, but now I have no way to refer to any files in my project without hardcoding their path! CARGO_MAKE_WORKING_DIRECTORY in the current task will return the temporary directory, and saving it in another environment variable before the cwd change in another task that run_tasks the real one just returns a relative path in the form of "."

In fact, as far as i can tell, CARGO_MAKE_WORKING_DIRECTORY doesn't work for anything? It only ever returns ".", unless you set cwd to an absolute path. In which case you know where you are anyway so don't need it?

Can CARGO_MAKE_WORKING_DIRECTORY somehow be canonicalized, or another variable exposed that is?

Alternatively, expose an environment variable CARGO_MAKE_CRATE_MANIFEST, which would be the full path to Cargo.toml?

[sagiegurari]

file system paths is always an issue with windows, but will make it work

[DianaNites]

Can't you just call std::fs::canonicalize on the path? That should make it absolute. If the problem is the leading //?/, it's safe to just remove them?

[sagiegurari]

ya hose leading chars it on windows caused me grief

[DianaNites]

In that case it should be safe to just unconditionally remove them after canonicalizing

[sagiegurari]

@DianaNites I pushed the change for windows in the 0.15.2 branch.
if you can verify it in your env please as well?

[sagiegurari]

pushed to master and will be officially released today