When using pre-build commands cross build hangs under Windows

[Danvil]

Checklist

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

Describe your issue

When I am adding a Cross.toml file with pre-build commands the build hands indefinitely. The identical setup is working when doing the build from Linux, so this seems to be a Windows-specific problem.

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

0.2.5

Example

My Cross.toml file:

# Install libudev into the machine for gilrs and serialport
[target.aarch64-unknown-linux-gnu]
pre-build = [
    "dpkg --add-architecture $CROSS_DEB_ARCH",
    "apt-get update && apt-get install -y pkg-config libudev-dev:$CROSS_DEB_ARCH",
]

Additional information / notes

The console output:

PS I:\myproj> cross build --release -p myapp --target=aarch64-unknown-linux-gnu -v
+ cargo metadata --format-version 1 --filter-platform aarch64-unknown-linux-gnu
+ rustc --print sysroot
+ rustup toolchain list
+ rustup target list --toolchain stable-x86_64-unknown-linux-gnu
+ rustup component list --toolchain stable-x86_64-unknown-linux-gnu
+ "C:\Program Files\RedHat\Podman\podman.exe"
+ "I:\\myproj" "C:\Program Files\RedHat\Podman\podman.exe" build --label 'org.cross-rs.for-cross-target=aarch64-unknown-linux-gnu' --label 'org.cross-rs.workspace_root=I:\myproj' --tag cross-custom-myproj:aarch64-unknown-linux-gnu-207c1-pre-build --build-arg 'CROSS_CMD=dpkg --add-architecture $CROSS_DEB_ARCH
apt-get update && apt-get install -y pkg-config libudev-dev:$CROSS_DEB_ARCH' --build-arg 'CROSS_DEB_ARCH=arm64' --file 'I:\myproj\target\aarch64-unknown-linux-gnu\Dockerfile.aarch64-unknown-linux-gnu-custom' 'I:\myproj'

[Emilgardis]

I doubt this is a cross issue.

Does running

podman build --label 'org.cross-rs.for-cross-target=aarch64-unknown-linux-gnu' --label 'org.cross-rs.workspace_root=I:\myproj' --tag cross-custom-myproj:aarch64-unknown-linux-gnu-207c1-pre-build --build-arg 'CROSS_CMD=ls' --build-arg 'CROSS_DEB_ARCH=arm64' --file 'I:\myproj\target\aarch64-unknown-linux-gnu\Dockerfile.aarch64-unknown-linux-gnu-custom' 'I:\myproj'

work? if it doesn't then you'll need to figure out what's wrong with podman build

[Emilgardis]

basically, copy the command cross is running, be careful with copying --build-arg 'CROSS_CMD=... as it will contain newlines

[Danvil]

I did a bit of investigation and found this: containers/podman#17628

The moment pre-build commands are added to the Cross.toml the workspace folder is used as the "context directory" and Windows podman copies the full context directory to its environment.

In a standard rust project the rust "target" folder is directly in the workspace folder and thus inside that "context directory". In my case a "fresh" cargo build after clean already produced about 1 GB of build artifacts. That alone prolongs the cross build by about ~1 minute. For some reason copying files into the podman image is quite slow (my guess is the default windows defender has something to do with it).

In addition in my case the workspace folder holds an additional ~15 GB of assets which creates the impression that cross build "hangs forever".

So I would consider this an issue with cross, as a even a small rust project with dependencies produces a target folder in the order of several GB which slow down the cross build process significantly to the point where it looks as if it never makes any progress. Those build artifacts should not be copied into the podman image. Additionally it would be great if Cross.toml would allow configuration to "ignore" certain subdirectories from the "context directory".

[Emilgardis]

Use cross installed from main, we switched to build with buildx (and podman should also support it if installed). Buildx doesn't needlessly copy all files and folders.

you can also add a .containerignore file at the root of the workspace that includes target as a ignored folder.

[Danvil]

.containerignore is working!

Thank you for the help 🙏

[AndreyMZ]

Use cross installed from main

Why not make a new release?

.containerignore is working!

It is good to have a workaround. But it is not an expected behavior, therefore could someone reopen this issue until a fixed version is released, please?

[Emilgardis]

I don't think this warrants reopening, the issue is expected behaviour, just happens to work better in newer code base.

I want to make a new release, but I don't feel like i's ready yet

[AndreyMZ]

the issue is expected behaviour

By "expected" I mean expected by users. As a user, I can definitely say that it was not expected. Otherwise, the reporter would not have created this issue, and I wouldn't have been searching for it.

I don't think this warrants reopening

As you wish. But I should warn that the decision to close unfixed issues leads to duplicate issues (not everyone searches for a similar issue among the closed ones before creating a new one), which means wasting time for both reporters and maintainers.

[Emilgardis]

But the issue is fixed/made irrelevant, just not released as a version, but I understand what you mean and appreciate the direction @AndreyMZ !

One thing with that though, we have a checkmark in the issue template that basically asks users to look through all issues, so hopefully we can mitigate some of that.

We have other completed issues that are only solved on coming 0.3.0 release, my only known praxis of how to handle issues is to close them when a fix is not possible or made available on the default (or backported) branch. But maybe that is bad maintence? I for one don't mind doing it that way anyway, but always open for improvement!