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:
|
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
Describe the problem
For now, when compiling a project, the final filename for the binary depends on the OS, as stated in the
build.rsfile here for instance:tauri/tooling/cli/src/build.rs
Lines 211 to 225 in 82c7855
I could successfully manage to cross-compile the project by using cross-rs/cross as runner instead of Cargo, with this command:
(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.dllnext to the.exefile, which is another subject).However, the build command still fails like this:
The reason is that the
my-project-namefile doesn't exist: it was built for Windows, so it is instead namedmy-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.rscode linked above should change behavior:Instead of using something like this to determine the file 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