[bug] When using a global `build.target-dir` for Cargo, `cargo tauri dev` panics at 'failed to rename app'.

[dsaghliani]

Describe the bug

When using a global target-dir for all projects (instead of storing the builds in the project folder, Cargo writes to ~/.cargo_builds), cargo tauri dev panics, because "no such file or directory" exists. At a guess, the build script doesn't expand to the full path and ends up looking for a local .cargo_builds.

Reproduction

1. Go to the Cargo installation (on Linux, ~/.cargo).
2. Create config.toml if it doesn't already exist.
3. Add the following inside:

[build]
target-dir = ".cargo_builds"

4. Create a sample front end. In my case, I used Vite with Svelte.
5. Initialize the Tauri back end.
6. Configure the build settings in src-tauri/tauri.conf.json.
7. Run cargo tauri dev.

Expected behavior

The project should build and a Tauri app window should open. This happens when not using a global target-dir.

Platform and versions

Environment
  › OS: Pop!_OS 22.04 X64
  › Node.js: 18.2.0
  › npm: 8.9.0
  › pnpm: Not installed!
  › yarn: Not installed!
  › rustup: 1.24.3
  › rustc: 1.61.0
  › cargo: 1.61.0
  › Rust toolchain: stable-x86_64-unknown-linux-gnu 

Packages
  › @tauri-apps/cli [NPM]: 1.0.3
  › @tauri-apps/api [NPM]: Not installed!
  › tauri [RUST]: 1.0.3,
  › tauri-build [RUST]: 1.0.3,
  › tao [RUST]: 0.12.1,
  › wry [RUST]: 0.19.0,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../dist
  › devPath: http://localhost:3000/
  › framework: Svelte

App directory structure
  ├─ src-tauri
  ├─ node_modules
  ├─ public
  ├─ .vscode
  ├─ dist
  └─ src

Stack trace

thread '<unnamed>' panicked at 'failed to rename app: failed to rename `.cargo_builds/debug/app` to `.cargo_builds/debug/ff-filter-svelte`

Caused by:
    No such file or directory (os error 2)', /home/dsaghliani/.cargo/registry/src/github.com-1ecc6299db9ec823/tauri-cli-1.0.3/src/interface/rust.rs:340:58
stack backtrace:
   0:     0x56540dc488e1 - std::backtrace_rs::backtrace::libunwind::trace::h22893a5306c091b4
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x56540dc488e1 - std::backtrace_rs::backtrace::trace_unsynchronized::h29c3bc6f9e91819d
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x56540dc488e1 - std::sys_common::backtrace::_print_fmt::he497d8a0ec903793
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x56540dc488e1 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9c2a9d2774d81873
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x56540da69dbc - core::fmt::write::hba4337c43d992f49
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/fmt/mod.rs:1194:17
   5:     0x56540dc1aa54 - std::io::Write::write_fmt::heb73de6e02cfabed
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/io/mod.rs:1655:15
   6:     0x56540dc4b39a - std::sys_common::backtrace::_print::h63c8b24acdd8e8ce
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x56540dc4b39a - std::sys_common::backtrace::print::h426700d6240cdcc2
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x56540dc4b39a - std::panicking::default_hook::{{closure}}::hc9a76eed0b18f82b
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:295:22
   9:     0x56540dc4b049 - std::panicking::default_hook::h2e88d02087fae196
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:314:9
  10:     0x56540dc4bf3a - std::panicking::rust_panic_with_hook::habfdcc2e90f9fd4c
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:698:17
  11:     0x56540dc4be52 - std::panicking::begin_panic_handler::{{closure}}::he054b2a83a51d2cd
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:588:13
  12:     0x56540dc4bdc6 - std::sys_common::backtrace::__rust_end_short_backtrace::ha48b94ab49b30915
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:138:18
  13:     0x56540dc4bd82 - rust_begin_unwind
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
  14:     0x56540d9d5582 - core::panicking::panic_fmt::h366d3a309ae17c94
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
  15:     0x56540d9d5782 - core::result::unwrap_failed::hddd78f4658ac7d0f
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/result.rs:1785:5
  16:     0x56540dcef5b1 - tauri_cli::interface::rust::Rust::run_dev::{{closure}}::he4c69b810725a924
  17:     0x56540dceea5e - std::sys_common::backtrace::__rust_begin_short_backtrace::hd6fc1b3325984561
  18:     0x56540dce6102 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h59cc13437e0b1ac9
  19:     0x56540dc4df05 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::ha99802c2c52ada61
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/boxed.rs:1861:9
  20:     0x56540dc4df05 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::ha39aea1c57e28a15
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/boxed.rs:1861:9
  21:     0x56540dc4df05 - std::sys::unix::thread::Thread::new::thread_start::h9f8e3d72b1f7662f
                               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys/unix/thread.rs:108:17
  22:     0x7fd3a7b4bb43 - <unknown>
  23:     0x7fd3a7bdda00 - <unknown>
  24:                0x0 - <unknown>

Additional context

No response

[jhutchins]

I'm able to produce this same issue on macOS 12.3 without setting target-dir. A completely vanilla install will produce this issue, and it doesn't, at least in my case, be related to path expansion since the error include full path name.

Compiling app v0.1.0 (/Users/jeffrey.hutchins/mine/temp/tauri-app/src-tauri)
    Finished dev [unoptimized + debuginfo] target(s) in 5.51s
thread '<unnamed>' panicked at 'failed to rename app: failed to rename `/Users/jeffrey.hutchins/mine/temp/tauri-app/src-tauri/target/debug/app` to `/Users/jeffrey.hutchins/mine/temp/tauri-app/src-tauri/target/debug/tauri-app`

Caused by:
    No such file or directory (os error 2)', /Users/jeffrey.hutchins/.cargo/registry/src/github.com-1ecc6299db9ec823/tauri-cli-1.0.2/src/interface/rust.rs:312:70
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Platform and versions

Environment
  › OS: Mac OS 12.3.0 X64
  › Node.js: 16.15.1
  › npm: 8.11.0
  › pnpm: Not installed!
  › yarn: Not installed!
  › rustup: 1.24.3
  › rustc: 1.62.0
  › cargo: 1.62.0
  › Rust toolchain: stable-x86_64-apple-darwin 

Packages
  › @tauri-apps/cli [NPM]: 1.0.3
  › @tauri-apps/api [NPM]: 1.0.2
  › tauri [RUST]: 1.0.3,
  › tauri-build [RUST]: 1.0.3,
  › tao [RUST]: 0.12.1,
  › wry [RUST]: 0.19.0,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../dist
  › devPath: ../dist

App directory structure
  ├─ dist
  ├─ node_modules
  └─ src-tauri

[jhutchins]

Installing progressively older versions of cargo-tauri indicates that the issue was introduced in 1.0.1. I'm going to attack it with git bisect and figure out what commit the issue was introduced. That should make the fix easier to determine unless someone already knows what the issue is and how to fix it.

[jhutchins]

After bisecting it appears the issue was added in b025b9f581ac1a6ae0a26789c2be1e9928fb0282 which I suppose makes sense since that's associated with #4447 which is about setting the binary name.

[lucasfernog]

Custom target dir isn't supported at the moment though we could implement it.

@jhutchins can you share your Cargo.toml? we do have some known issues regarding it (specially if you use [[bin]]). The plan is to fix it for the next release.

[dsaghliani]

@lucasfernog Support would be appreciated. I'm new to Tauri, but if it's a simple-enough change—and it probably is—I can help.

[jhutchins]

@lucasfernog here is my Cargo.toml

[package]
name = "app"
version = "0.1.0"
description = "A Tauri App"
authors = ["you"]
license = ""
repository = ""
default-run = "app"
edition = "2021"
rust-version = "1.57"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[build-dependencies]
tauri-build = { version = "1.0.3", features = [] }

[dependencies]
serde_json = "1.0"
serde = { version = "1.0", features = ["derive"] }
tauri = { version = "1.0.3", features = ["api-all"] }

[features]
# by default Tauri runs in production mode
# when `tauri dev` runs it is executed with `cargo run --no-default-features` if `devPath` is an URL
default = [ "custom-protocol" ]
# this feature is used used for production builds where `devPath` points to the filesystem
# DO NOT remove this
custom-protocol = [ "tauri/custom-protocol" ]

My reproduction steps are pretty straight froward. I just follow the Getting Started guide.

$ cargo install tauri-cli --version "^1.0.0"
$  npm create tauri-app
? What is your app name? tauri-app
? What should the window title be? Tauri App
? What UI recipe would you like to add? Vanilla.js (html, css, and js without the bundlers)
$ cd tauri-app
$ npm install
$ npm run tauri dev

The error isn't crazy, it is correct that there is no file /Users/jeffrey.hutchins/mine/temp/tauri-app/src-tauri/target/debug/app it is instead at /Users/jeffrey.hutchins/mine/temp/tauri-app/src-tauri/target/x86_64-apple-darwin/debug/app I'm not sure if storing the build artifact under a target triple specific folder is strange or common behavior since I've not really dug deeply into how cargo stores build artifacts previously.

[lucasfernog]

@jhutchins can you share the output of rustup target list and rustup toolchain list? Storing the build artifact under a target triple specific folder is a Cargo behavior, but it should only do that if you specify a custom target (so using the default one should store artifacts under src-tauri/target/debug unless you configure Cargo to do something else.

[jhutchins]

@lucasfernog

❯ rustup target list
aarch64-apple-darwin
aarch64-apple-ios (installed)
aarch64-apple-ios-sim (installed)
aarch64-fuchsia
aarch64-linux-android (installed)
aarch64-pc-windows-msvc
aarch64-unknown-linux-gnu
aarch64-unknown-linux-musl
aarch64-unknown-none
aarch64-unknown-none-softfloat
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armebv7r-none-eabi
armebv7r-none-eabihf
armv5te-unknown-linux-gnueabi
armv5te-unknown-linux-musleabi
armv7-linux-androideabi (installed)
armv7-unknown-linux-gnueabi
armv7-unknown-linux-gnueabihf
armv7-unknown-linux-musleabi
armv7-unknown-linux-musleabihf
armv7a-none-eabi
armv7r-none-eabi
armv7r-none-eabihf
asmjs-unknown-emscripten
i586-pc-windows-msvc
i586-unknown-linux-gnu
i586-unknown-linux-musl
i686-linux-android (installed)
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-freebsd
i686-unknown-linux-gnu
i686-unknown-linux-musl
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips64-unknown-linux-gnuabi64
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-gnuabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
nvptx64-nvidia-cuda
powerpc-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
riscv32i-unknown-none-elf
riscv32imac-unknown-none-elf
riscv32imc-unknown-none-elf
riscv64gc-unknown-linux-gnu
riscv64gc-unknown-none-elf
riscv64imac-unknown-none-elf
s390x-unknown-linux-gnu
sparc64-unknown-linux-gnu
sparcv9-sun-solaris
thumbv6m-none-eabi
thumbv7em-none-eabi
thumbv7em-none-eabihf
thumbv7m-none-eabi
thumbv7neon-linux-androideabi
thumbv7neon-unknown-linux-gnueabihf
thumbv8m.base-none-eabi
thumbv8m.main-none-eabi
thumbv8m.main-none-eabihf
wasm32-unknown-emscripten
wasm32-unknown-unknown
wasm32-wasi
x86_64-apple-darwin (installed)
x86_64-apple-ios (installed)
x86_64-fortanix-unknown-sgx
x86_64-fuchsia
x86_64-linux-android (installed)
x86_64-pc-solaris
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
x86_64-sun-solaris
x86_64-unknown-freebsd
x86_64-unknown-illumos
x86_64-unknown-linux-gnu (installed)
x86_64-unknown-linux-gnux32
x86_64-unknown-linux-musl (installed)
x86_64-unknown-netbsd
x86_64-unknown-none
x86_64-unknown-redox

❯ rustup toolchain list
stable-x86_64-apple-darwin (default)
nightly-x86_64-apple-darwin

[lukelex]

Changing the app name in my cargo.toml solved the issue for me.

- name = "app"
+ name = "same-name-as-in-my-package.json-file"

Update Disregard this. False positive.