[feat] Use configured target triple for filename

[Pierstoval]

Describe the problem

For now, when compiling a project, the final filename for the binary depends on the OS, as stated in the build.rs file here for instance:

tauri/tooling/cli/src/build.rs

Lines 211 to 225 in 82c7855

	if let Some(product_name) = config_.package.product_name.clone() {
	#[cfg(windows)]
	let product_path = out_dir.join(format!("{}.exe", product_name));
	#[cfg(target_os = "macos")]
	let product_path = out_dir.join(product_name);
	#[cfg(target_os = "linux")]
	let product_path = out_dir.join(product_name.to_kebab_case());
	rename(&bin_path, &product_path).with_context(|| {
	format!(
	"failed to rename `{}` to `{}`",
	bin_path.display(),
	product_path.display(),
	)
	})?;
	}

I could successfully manage to cross-compile the project by using cross-rs/cross as runner instead of Cargo, with this command:

$ cargo-tauri build --target=x86_64-pc-windows-gnu --runner=$HOME/.cargo/bin/cross

(executed in Ubuntu 20.04 in WSL 2 on a Windows 10 machine)

The binary is built, I can even run it (but only if I copy WebView2Loader.dll next to the .exe file, which is another subject).

However, the build command still fails like this:

❯ cargo-tauri build --target=x86_64-pc-windows-gnu --runner=$HOME/.cargo/bin/cross                                                                                                                                                       16:26:15
   Compiling my-project-name v0.1.0 (/project)
    Finished release [optimized] target(s) in 46.73s
Error: failed to rename `/var/www/my-project/src-tauri/target/x86_64-pc-windows-gnu/release/my-project-name` to `/var/www/my-project/src-tauri/target/x86_64-pc-windows-gnu/release/my-project-name`

Caused by:
    No such file or directory (os error 2)

The reason is that the my-project-name file doesn't exist: it was built for Windows, so it is instead named my-project-name.exe.

Describe the solution you'd like

The solution to make it work seems (according to the code I read in the tauri build process) that the build.rs code linked above should change behavior:

Instead of using something like this to determine the file name:

    #[cfg(windows)]
    let product_path = out_dir.join(format!("{}.exe", product_name));

Tauri should instead rely on determining whether it has to add .exe (or if it has to convert it to "kebab case" as of the linux-specific code we can see later in the file) depending on the target triple rather than what OS is building the project.

I don't really know if this is feasible, especially considering the amount of different target triples (there's a list of target triples in the Cross repository), but I guess it might benefit future cross-compilation-based features.

Alternatives considered

For now, the only alternative is to "just ignore" the error with shell features, which is not optimal since one has to add other shell commands to see if the project has actually been successfully built or not.

Additional context

No response

[FabianLars]

I almost think trying to find both files (first exe, after that without extension) would be more reliable (and ofc easier).

Also keep in mind that we explicitly don't support cross-compilation yet, so no promises that a fix for this will make it into V1 stable :)

[Pierstoval]

I almost think trying to find both files (first exe, after that without extension) would be more reliable (and ofc easier).

Indeed! Do you want me to work on a small patch? I'm not sure to have all the necessary knowledge about the builder's workflow, but I can try 👍

Also keep in mind that we explicitly don't support cross-compilation yet, so no promises that a fix for this will make it into V1 stable :)

This wouldn't be "explicit cross-compilation support", it would be more like "making it easier for nerdies trying edge-case cross-compilation", and since it shouldn't (and musn't) have any impact on the project, I guess it's fine 😇

[FabianLars]

it would be more like "making it easier for nerdies trying edge-case cross-compilation"

Which is pretty much what I meant. Our (human) resources are scarce and since it blocks only something we explicitly don't support (aka spend much time on) we make no promises that it will make it into vs. Especially since we need to make sure that it doesn't break anything (tbf that would be really weird for such a simple change).

That said "no promises" does not mean that it can't make it into it, especially if someone opens a PR for it. (Also on a side note, have in mind that we always have to make sure to not invalidate the audit)

Do you want me to work on a patch?

Sure why not ❤️ Can't hurt if you got the time.

[betamos]

Note that there's some shared logic with sidecar (external) binaries as well, might even be reusable code that can be plugged in. IIRC we use target triple to choose input file on those. There's some benefit in terms of total system complexity if input filename is deterministic. To me, it sounds like assuming input filename from current OS is just a plain old bug. Just my 2c.

it would be more like "making it easier for nerdies trying edge-case cross-compilation"

+1 on this. One positive of this approach is that if/when we want explicit support, we have a head start with a set of known issues from exactly (us) nerdies :)

[lucasfernog]

The CLI is not designed for cross compilation at all (even the WiX bundling will fail). The rename issue is the easier to fix though.

[Pierstoval]

There's some benefit in terms of total system complexity if input filename is deterministic.

Something like if target_triple matches "windows" would still be deterministic IMO.

The CLI is not designed for cross compilation at all (even the WiX bundling will fail). The rename issue is the easier to fix though.

That's the main and sole point of this issue! Because a successful cross-compilation would be (hopefully) the only side-effect of such change!

If you're okay, I'll open a PR soon 😉

[lucasfernog]

Yeah I agree with that approach @Pierstoval

[Pierstoval]

PR opened there: #4032

I have some questions, if you could check them out when you have enough time and energy 👍

[Pierstoval]

Seems like a new bug was introduced in normal build:

$ tauri build
   Compiling csr v0.1.0 (C:\dev\cacs-rg\src-tauri)
    Finished release [optimized] target(s) in 1m 52s
Error: failed to rename `C:\dev\cacs-rg\src-tauri\target\release\csr..exe` to `C:\dev\cacs-rg\src-tauri\target\release\csr..exe`

Caused by:
    Le fichier spécifié est introuvable. (os error 2)

Will try to provide a fix this afternoon 😅

[Pierstoval]

Fixed in #4055