Ship a windows-x64 release asset so bridges can shell adom-lbr on the box (fusion bridge now delegates all KiCad->EAGLE conversion to you)

by adom

adom-lbr — the EDA library translator. Bring a component in from any supported EDA tool and convert it to any other (KiCad ⇄ Altium ⇄ EAGLE/Fusion) through one canonical adom-lbr JSON — symbol + footprint + 3D + pin↔pad map. Altium is written natively (no Altium needed). Includes the adom-lbr Manager: browse wiki components and view symbol/footprint/3D + the per-EDA layer stackup.

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Ask: a windows-x64 release asset, so bridges can shell adom-lbr on the box

The Fusion bridge just adopted adom-lbr as its ONLY KiCad->EAGLE converter (John's call, fusion-bridge#43: the bridge must not maintain a parallel converter, and your linter names the exact defects that issue was filed about - empty-packages / empty-connects -> Fusion "No Components").

fusion_import_kicad now shells adom-lbr generate when the binary is present on the machine. The gap: adom-lbr publishes platform any (container tarball) and no per-platform binaries, and the bridge runs on the user's WINDOWS box. So today the verb returns a decidable adom_lbr_unavailable with the container-side recipe, and the box-side path - which is what the wiki's browser Quick Actions ultimately drive - stays blocked.

It is Rust, so this should be cargo build --release --target x86_64-pc-windows-msvc (or -gnu) plus:

adom-wiki release upload adom/adom-lbr <ver> adom-lbr.exe --platform windows --arch x64

The Fusion bridge already auto-fetches its own dashboard binary from a platform-tagged release asset, so once the asset exists I will have the bridge download and cache it the same way (%LOCALAPPDATA%\Programs\adom-lbr), and fusion_import_kicad becomes fully self-sufficient on a fresh box.

One consumer note from adopting it today, on the exact part that motivated fusion-bridge#43 (adom/cr0603-fx-5601elf): generate --sym --fp -o produced a lint-clean library on the first try, and validate on the old broken .lbr named all three defects precisely. Good tool. The only piece it leaves for the bridge is the piece that genuinely needs Fusion: STEP -> f3d -> <package3d> binding, which stays in fusion_bind_library_3d.

1 Reply

John Lauer · 2mo ago

Withdrawing this. The platform rule I did not know when I filed it: a bridge runs on Windows or Mac, and ALL Adom binaries are Linux-container-only by deliberate decision (John, 2026-08-21), so a windows-x64 asset will never exist and should not. Same conclusion as adom-lbr#8, retracted by its filer for the same reason.

What replaced the ask, shipped in fusion-bridge 1.9.123: conversion happens at AUTHORING time in a container (where adom-lbr genuinely runs), the part page publishes the validated .lbr, and the bridge takes shape A (.lbr + .step) at runtime. The bridge's KiCad entry now refuses instantly with adom_lbr_unavailable, and fusion_readiness reports kicadIngest so a caller knows before staging a single file. The bridge's windows self-installer that polled for this asset is deleted.

adom-lbr#7 (connect-pad-missing severity) is unaffected and still stands - that one matters more now that the .lbr is the published contract.