Jake
089349d966
Phase 2 of the rebrand cascade. Renames all 9 workspace crates from magnotia-* to lumotia-* plus the src-tauri binary crate name: - magnotia-ai-formatting -> lumotia-ai-formatting - magnotia-audio -> lumotia-audio - magnotia-cloud-providers -> lumotia-cloud-providers - magnotia-core -> lumotia-core - magnotia-hotkey -> lumotia-hotkey - magnotia-llm -> lumotia-llm - magnotia-mcp -> lumotia-mcp - magnotia-storage -> lumotia-storage - magnotia-transcription -> lumotia-transcription - magnotia -> lumotia (src-tauri binary) - magnotia_lib -> lumotia_lib (src-tauri lib target) Crate directories (crates/audio/ etc.) stay as-is; only the Cargo.toml [package] name field changes plus all consumer module imports (magnotia_core -> lumotia_core, etc.). Remaining magnotia_* references at this point are intentional and scoped to later phases: tracing targets (Phase 4), DB setting keys magnotia_preferences/magnotia_history (Phase 5). cargo build --workspace passes. cargo test --workspace: 330 pass, 0 fail. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
74 lines
2.8 KiB
Rust
74 lines
2.8 KiB
Rust
//! Build-time guard for item #6 of the Whisper ecosystem pass.
|
|
//!
|
|
//! On Windows, linking `whisper-rs-sys` (MSVC C++ runtime) and the
|
|
//! `tokenizers` crate (which pulls a different MSVC CRT via its
|
|
//! onnxruntime + Rust-side dependencies) in the same binary has been a
|
|
//! repeated failure mode — most recently Whispering v7.11.0 shipped a
|
|
//! broken Windows build over exactly this conflict. Reference:
|
|
//! https://github.com/EpicenterHQ/epicenter/releases/tag/v7.11.0
|
|
//!
|
|
//! The easiest defence is to refuse to compile at all if any part of the
|
|
//! workspace ever pulls `tokenizers` into the dependency graph on a
|
|
//! Windows target. If we ever legitimately need it we can reintroduce
|
|
//! it via a sidecar (isolated process, separate CRT) rather than
|
|
//! linking it into `lumotia_lib`.
|
|
//!
|
|
//! The check is advisory on non-Windows targets — it still prints a
|
|
//! cargo:warning if `tokenizers` appears, so the Windows failure isn't
|
|
//! a surprise at CI time when we build cross-platform from Linux.
|
|
|
|
use std::env;
|
|
use std::fs;
|
|
use std::path::PathBuf;
|
|
|
|
fn main() {
|
|
println!("cargo:rerun-if-changed=build.rs");
|
|
|
|
let target_os = env::var("CARGO_CFG_TARGET_OS").unwrap_or_default();
|
|
let manifest_dir = PathBuf::from(env::var("CARGO_MANIFEST_DIR").unwrap_or_else(|_| ".".into()));
|
|
|
|
// Walk up to workspace root: crates/transcription/ -> crates/ -> root
|
|
let workspace_root = manifest_dir
|
|
.ancestors()
|
|
.find(|p| p.join("Cargo.lock").exists())
|
|
.map(PathBuf::from);
|
|
|
|
let Some(root) = workspace_root else {
|
|
// No lockfile yet (e.g. first-ever cargo run). Nothing to check.
|
|
return;
|
|
};
|
|
|
|
let lock_path = root.join("Cargo.lock");
|
|
println!("cargo:rerun-if-changed={}", lock_path.display());
|
|
|
|
let lock = match fs::read_to_string(&lock_path) {
|
|
Ok(s) => s,
|
|
Err(_) => return,
|
|
};
|
|
|
|
let has_tokenizers = lock
|
|
.lines()
|
|
.any(|line| matches!(line.trim(), "name = \"tokenizers\""));
|
|
|
|
if !has_tokenizers {
|
|
return;
|
|
}
|
|
|
|
if target_os == "windows" {
|
|
panic!(
|
|
"magnotia-transcription: the `tokenizers` crate appears in Cargo.lock and this is a \
|
|
Windows build. Linking `whisper-rs-sys` + `tokenizers` in the same binary has \
|
|
been a persistent MSVC C-runtime conflict (see Whispering v7.11.0). Route any \
|
|
tokenizer usage through an out-of-process sidecar instead, or gate it off for \
|
|
Windows. Brief item #6."
|
|
);
|
|
}
|
|
|
|
println!(
|
|
"cargo:warning=magnotia-transcription: `tokenizers` crate is in the dependency graph. \
|
|
This build is non-Windows so the link will succeed, but Windows builds will panic \
|
|
at build time per docs/whisper-ecosystem/brief.md item #6. Isolate tokenizer usage \
|
|
in a sidecar before a Windows ship."
|
|
);
|
|
}
|