#Dummy macro #[tauri_command]
23 messages · Page 1 of 1 (latest)
Compiling in Rust shouldn't be slow after the first time. Are you using a cloud platform for building? Most offer some form of caching build artifacts.
Compiling Rust without Tauri is fast (some small first things), but not with Tauri - on my system. - E. g, just after deleting an empty line: "Finished dev [unoptimized + debuginfo] target(s) in 1m 15s" - but I also had considerably longer times.
Yeah, 1 minute is about what I get with VMs.
It definitely takes a while to repack the final binary. Unfortunately, Rust doesn't have a syntax for build flags on macros, it will consider the whole function as behind the flag. What you can do is make your #[tauri::command] into a basic wrapper and keep as much of the business logic in functions that don't have the macro. Then you can set a build flag on all the functions with the macro so it doesn't try to compile them when you're testing.
For an iterative build??? Over a minute for that usually means that there's a bug or something that makes rust invalidate the whole, or part of the target dir.
Or at least so i thought
@fluid basalt What's your devPath and distDir set to? And does running cargo build with and without the custom-protocol feature flag directly make a difference?
"build": {
"beforeBuildCommand": "",
"beforeDevCommand": "",
"devPath": "../ui",
"distDir": "../ui",
"withGlobalTauri": true
},
I don't know the custom-protocol feature flag or how to set it. I'm just a few steps beyond "Hello World" in Rust and Tauri.
(in your src-tauri dir)
First run this: cargo build
After that, this: cargo build --features custom-protocol
Then compare the time both of them took
Also, how large is your ui folder (in MB)?
the ui is 12 KB 🙂 and build without the flag: Finished dev [unoptimized + debuginfo] target(s) in 3m 47s
And the same with the flag now: cargo build --features custom-protocol
Compiling tauri v1.5.4
Compiling tauri-macros v1.4.3
Compiling app v0.1.0 (D:\Rust\projects\WioTauri\src-tauri)
Finished dev [unoptimized + debuginfo] target(s) in 3m 14s
(I have to leave now, will be back later)
But my original question was a Rust question: How can I define and use a dummy "#[tauri_command]", so that I can test some modules without Tauri?
There's a lot of bottlenecks in my pipeline. The files themselves are on the base machine in an encrypted volume then passed to the VM through virtiofs. It's about 10% slower versus local files in the VM. I've never tried compiling Rust on the base machine so I have no measure of comparison for that.
I thought of a better solution than the one I provided earlier: make a fake tauri crate with a no-op macro and put it behind a build flag.
how can I do that? As I said, I'm close to Hello World level 🙂
Run the following somewhere outside of src-tauri (and preferably not in src either).
cargo new --lib fake-tauri
Add the following to fake-tauri/Cargo.toml:
[features]
custom-protocol = []
[lib]
proc-macro = true
Replace fake-tauri/src/lib.rs with the following:
extern crate proc_macro;
use proc_macro::TokenStream;
#[proc_macro_attribute]
pub fn command(_attributes: TokenStream, item: TokenStream) -> TokenStream {
item
}
Reference the impersonator crate in src-tauri/Cargo.toml:
[build-dependencies]
#tauri-build = { version = "1.5", features = [] }
[dependencies]
#tauri = { version = "1.5", features = ["shell-open"] }
tauri = { path = "../fake-tauri" }
[features]
# ...
test-build = []
Add the feature flag to src-tauri/build.rs:
#[cfg(not(feature = "test-build"))]
tauri_build::build()
Start the app:
cargo run --features="test-build"
As it turns out, you can't change crates based on build flags. Dependency 'tauri' has different source paths depending on the build target. Each dependency must have a single canonical source path irrespective of build target.
You'll just have to modify src-tauri/Cargo.toml every time you want to test without Tauri.
you could feature gate the tauri::command macro like so i think ```
#[cfg_attr(feature = "feature-name", tauri::command)]
fn abc() {}