[bug] error[E0252]: webview_version defined multiple times when both wry and cef features active

[bl4z3ng41n]

Describe the bug

When building with features = ["cef"] on Linux, both tauri_runtime_wry and tauri_runtime_cef are compiled, causing a name conflict:

error[E0252]: the name webview_version is defined multiple times

 --> crates/tauri/src/lib.rs:232:9

Cause: Both re-exports compile simultaneously:

// line 228
pub use tauri_runtime_wry::webview_version;
// line 232  
pub use tauri_runtime_cef::webview_version;

Temporary Fix: Gate the wry export behind not(feature = "cef"):

line 226, change:

#[cfg(feature = "wry")]
//to:
#[cfg(all(feature = "wry", not(feature = "cef")))]

Environment: Linux (Arch), Tauri feat/cef branch @ 562bc59

Reproduction

No response

Expected behavior

No response

Full tauri info output

n/a

Stack trace

Additional context

No response

[FabianLars]

Sure we should fix this but I would also heavily recommend to turn off the wry feature when you enable cef. That would just bloat the dependencies and is borderline undefined behavior at the moment.

[bl4z3ng41n]

Thanks. This is also a good suggestion to test out. feat/cef looks promising and much more stable on Linux than webkit2gtk.

[devdotbo]

Concrete reproduction from a downstream consumer on feat/cef rev 562bc592b337de417aa48e72034c7816cfb4c142:

With the default wry feature still on and cef added on top, the dupe surfaces as:

error[E0252]: the name `webview_version` is defined multiple times

Fix that works for us is to drop the default features on the tauri crate in the consumer Cargo.toml (keeping only the non-runtime features we actually need), and let the cef feature come in explicitly:

tauri = { version = "2", default-features = false, features = ["compression", "common-controls-v6", "dynamic-acl"] }

One secondary gotcha worth flagging for anyone landing here: with wry off, tauri::AppHandle no longer has a default Runtime generic, so any consumer code that takes an AppHandle needs to be generic over R: Runtime. Mechanical fix, but cargo check surfaces it as a wall of expected 1 generic argument until you adjust.

Seconding @FabianLars' point that keeping both runtimes on at the same time is borderline UB. The default-features = false switch is the clean version of the same advice and removes the conflict entirely rather than relying on feature intersection working out.

[sftse]

Are feature flags the right mechanism to configure the runtime? They are more opaque and harder to discover than passing the runtime as an explicit parameter in the app builder.

Cargo features are usually considered to be additive.

[FabianLars]

No they are not. This is just temporary, see #15068 for one possible approach we're looking into.