Impossible to use volumes in a workspace that reference a parent directory

[vlovich]

Checklist

• I've looked through the issues and pull requests for similar reports

Describe your issue

I have a mega repo that looks something like:

./  # git root
|  --- workspace
     | --- crate1
     | --- crate2
     | --- folder/crate3   # [dependencies] crate1.path = "../../crate1"
|  --- some/other/path/schemas

I'm trying to get crate1 to reference cap'n'proto schemas that are located in the schemas folder. I have tried:

• Symlink schemas into crate1/schemas - not available within docker image since the symlink is pointing nowhere.
• Use volumes to set GIT_ROOT=../../ in workspace/Cross.toml. This works when building crate1 but building folder/crate3 results in GIT_ROOT pointing to workspace/ instead of "git root".

It would be much more convenient if it was guaranteed that relative paths within volumes were anchored relative to the location of Cross.toml / workspace Cargo.toml instead of floating with the crate that's getting built.

What target(s) are you cross-compiling for?

aarch64-unknown-linux-gnu

Which operating system is the host (e.g computer cross is on) running?

• macOS
• Windows
• Linux / BSD
• other OS (specify in description)

What architecture is the host?

• x86_64 / AMD64
• arm32
• arm64 (including Mac M1)

What container engine is cross using?

• docker
• podman
• other container engine (specify in description)

cross version

cross 0.2.5 (154b4ea 2025-12-15)

Example

No response

Additional information / notes

One workaround I've found is to have separate Cross.toml files within each crate set up the volume using the relative path correct for that crate but that's not generally scalable for workspaces with complex layouts. e.g.

./  # git root
|  --- workspace/Cross.toml - # build.env.volumes = ["GIT_ROOT=../../"] # default for all workspace/crate
     | --- crate1
     | --- crate2
     | --- folder/crate3/Cross.toml   # - build.env.volumes = ["GIT_ROOT=../../../"] # override for crate3
     | --- folder/crate4/Cross.toml   # - build.env.volumes = ["GIT_ROOT=../../../"] # override for crate4
     | --- folder/some-other-folder/crate5/Cross.toml   # - build.env.volumes = ["GIT_ROOT=../../../../"] # override for crate5
|  --- some/other/path/schemas

I think the relative paths should always get resolved relative to the file they are declared in. That makes it the least error prone. At a minimum, making them always relative to the workspace root would be fine too even though it would be mildly confusing why paths relative to the workspace are appearing within crate Cross.toml files.

[Emilgardis]

It's a little hard to understand/parse what you're asking for, but let me see if I understand.

The issue is that if you have a relative path in env.volumes the path it points to is relative to CWD, not the crate manifest path.

I think we can solve this, I'm not sure however if we need to be careful about breakage here, maybe it would be alright to just change this (I think this is where the magic happens)

cross/src/docker/shared.rs

Lines 1169 to 1176 in 426e811

	if let Ok(val) = value {
	let canonical_path = file::canonicalize(&val)?;
	let host_path = paths.mount_finder.find_path(&canonical_path, true)?;
	let mount_path = Path::new(&val).as_posix_absolute()?;
	mount_cb(self, host_path.as_ref(), mount_path.as_ref())?;
	self.args(["-e", &format!("{}={}", var, mount_path)]);
	store_cb((val, mount_path));
	}

or if we add a way to do $workspace/<path>

[vlovich]

Yeah, the path is relative to the CWD which within a workspace is the directory of the crate being built which requires every crate to have a flat structure for this to work. An explicit variable interpolation would work (& in that case supporting interpolating $vcs as well would also simplify some things where that expands to the git root).