Embed config-relative paths as a substring

[rhgndf]

Problem

Config env vars as far as I can tell cannot embed relative paths as a substring.

Proposed Solution

It would be useful to be able to set env vars like this for dependencies that need to compile C libraries.

[env]
CFLAGS = ["-I", { value = "include", relative = true }]

Notes

Useful if needed to modify how a library compiles for wasm32-unknown-unknown

[weihanglo]

Thanks for the report. It's a bit unclear what you want to achieve. Can you share a more complete example for your use case? Will environment variable expansion #10789 helps?

Besides, an unstable flag -C can change the current directory. Please have a look whether it is useful in this situation.

[rhgndf]

I think #10789 might work if it can expand env vars set within the cargo.toml.

For this feature request, it is to emulate setting the env var on the command line like CFLAGS="-I$(pwd)/include"

[weihanglo]

Pretty much understood. Just to me feel a bit awkward to have a nested { relative = "…" } inside an array. Personally I am looking forward to #10789 more.

@rustbot label -S-needs-design +S-needs-team-input +I-nominated-to-discuss -S-needs-info

[joshtriplett]

Slight bikeshed: this seems like it could be written more simply as { relative-path = "include" }.

[joshtriplett]

@rhgndf Could you please expand on your use case here? When we discussed this in a Cargo meeting, we weren't clear on exactly what the use case was. In particular, could you explain why this is relative to the config rather than the package root, and why -I include does not work? Are you looking to have a user-global environment variable with a relative path on it?

[rhgndf]

It seems like when compiling a dependency's C file the relative path does not start from the cargo.toml path. Maybe it starts from the dependency package root instead? I would like to use this feature to include some header files not present in wasm32-unknown-unknown in order to make the C source files from the dependency compile successfully.

[weihanglo]

Where is the .cargo/config.toml you expect Cargo to read, and where did you execute cargo build from?

Note that Cargo configurations .cargo/config.toml are probed starting from the current working directory. Any path not at the probe path will be ignored.

It would be helpful if you could provide a concrete layout of the project or a reproducible example.

[rhgndf]

Here's an example: https://github.com/rhgndf/configrelative

[JP-Ellis]

I've stumbled on this issue coming from another use-case: setting the rustdocflags.

In my case, I have:

.cargo
├── config.toml
├── katex.header.html
└── katex.script.html
Cargo.toml

and I would like to be able to set .cargo/config.toml to something like:

[build]
rustdocflags = [
  "--html-in-header", ".cargo/katex.header.html",
  "--html-after-context", ".cargo/katex.script.html"
]

This (as discussed above) does not work, but I think would be a good use-case to relative paths. This is in analogy to the docs.rs config that can be set:

[package.metadata.docs.rs]
rustdoc-args = [
  "--html-in-header", ".cargo/katex.header.html",
  "--html-after-content", ".cargo/katex.script.html",
]

Workaround

As a workaround, using direnv and the following .envrc file works:

export RUSTDOCFLAGS="${RUSTDOCFLAGS:-} --html-in-header $PWD/.cargo/katex.header.html"
export RUSTDOCFLAGS="${RUSTDOCFLAGS:-} --html-after-content $PWD/.cargo/katex.script.html"

This of course relies on any contributor having direnv configured though.