Empaquetar una herramienta ajena
Meter un binario de terceros en tu instalador: cómo se nombra por plataforma, cómo se encuentra en tiempo de ejecución, y las responsabilidades que se adquieren al hacerlo.
Qué se gana y qué cuesta
La convención de nombres
El problema que resuelve: un binario distinto por plataforma y arquitectura, empaquetando solo el que corresponde.
La convención es sufijar el nombre con el triple de destino de la plataforma:
binaries/ mitool-x86_64-apple-darwin mitool-aarch64-apple-darwin mitool-x86_64-pc-windows-msvc.exe mitool-x86_64-unknown-linux-gnuY en la configuración se declara sin el sufijo:
{ "bundle": { "externalBin": ["binaries/mitool"] } }El sistema de compilación elige el que corresponde al destino que estés construyendo y lo mete en el paquete con el nombre correcto. Si falta el del destino que compilas, la compilación falla — lo que es bueno: mejor un error de compilación que un instalador sin la herramienta.
Y el triple exacto se obtiene del propio compilador, no se escribe de memoria: es la fuente de errores más tonta de este nivel.
Ejecutarlo
use tauri_plugin_shell::ShellExt;let salida = app.shell() .sidecar("mitool")? // por su nombre lógico, sin sufijo .args(["--entrada", ruta]) .output() .await?;Tauri resuelve dónde está según el sistema —dentro del paquete de la aplicación en macOS, junto al ejecutable en Windows, donde corresponda en Linux— y eso evita el problema de rutas del nivel 45.5 por completo.
Y el permiso también es distinto: hay uno específico para ejecutar acompañantes, separado del de ejecutar programas arbitrarios. Usar ése y no el general es lo correcto: acota exactamente a lo que empaquetaste.
Las tres responsabilidades
La segunda es la que aparece de golpe y no en desarrollo: todo funciona hasta que firmas y notarizas, y entonces el sistema rechaza la aplicación por un binario interno sin firmar.