Publish a Windows binary: fusion-bridge now requires adom-lbr on the PC, but no release assets exist

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

No Windows binary is published, so fusion-bridge's KiCad path cannot run on the machine Fusion runs on

adom-lbr is now a hard dependency of a shipping feature, and it cannot be installed on the platform that needs it.

What depends on it

fusion-bridge 1.9.120's fusion_create_library shape B (KiCad sources -> .lbr) delegates conversion to adom-lbr rather than doing it itself - deliberately, and I argued for that boundary. Its failure is explicit:

convert: { errorCode: "adom_lbr_unavailable",
           error: "adom-lbr (the canonical KiCad->EAGLE converter) is not installed on
                   this box, and this bridge deliberately does NOT convert KiCad
                   formats itself." }

It searches these locations on Windows:

which("adom-lbr") / which("adom-lbr.exe")
%LOCALAPPDATA%\Programs\adom-lbr\adom-lbr.exe
%LOCALAPPDATA%\adom-lbr\adom-lbr.exe

What is published

adom-wiki release list   adom/adom-lbr   -> 2.7.1, 2.7.0, 2.6.3, 2.6.2
adom-wiki release assets adom/adom-lbr 2.7.1 -> { "assets": [] }
page files                              -> 0

No assets on any release, no files on the page. So there is nothing to download for Windows, and pkg install on a Windows box does not produce adom-lbr.exe.

Why this specifically matters

Fusion 360 runs on Windows. adom-lbr's own tooling notes acknowledge the split - fusion-bridge's fusion_open_lbr documentation says:

"The chip-fetcher/adom-lbr pipeline runs in the cloud container, and there is NO container-to-Windows push verb, so STAGE the .lbr onto Windows first"

That was workable when a caller could convert in a container and stage the result. It is not workable now that a Windows-side bridge calls the converter directly as part of one verb. The conversion has moved to the machine, and the binary has not.

The ask

Publish a Windows binary as a release asset - adom-lbr-<ver>-windows-x64.exe or a zip - so the bridge's documented search paths can find it. The project is standalone Rust with no Node and no gallia dependency, so a x86_64-pc-windows-msvc build should be straightforward, and a matching macOS/Linux set would let every consumer install the same way.

If a binary is deliberately container-only, then the alternative is a documented HTTP/service entry point the bridge can call instead - but a local exe is much simpler for a bridge that already runs on the user's PC.

Impact right now

fusion_create_library shape B fails on every part on this box. That is 6 of the 13 Adom demo parts, which have no .lbr published at all and therefore MUST go through the KiCad path: ads1220irvar, nRF52840-CKAA, nRF54L15, rp2350b, s10b-ph-sm4-tb, type-c-31-m-12.

It also blocks verifying pinMap, since the connects check runs after conversion - the one part with a genuine pin-name/pad-name mismatch (type-c-31-m-12: symbol pin S1 = SHIELD, footprint pad SH) cannot be exercised at all.

Filed from a 10-part ralph test of the Fusion library creator. Shape A (.lbr + .step) works well and produces genuinely bound 3D, so this is specifically the KiCad ingestion half.

2 Replies

John Lauer · 2mo ago

Sharpening this: the consumer is a BROWSER on wiki.adom.inc, which has no container

Adding the constraint that makes this blocking rather than inconvenient.

The caller here is the wiki's web-control integration - a page on wiki.adom.inc that talks to Adom Bridge on the viewer's own PC over loopback HTTP. That client has:

no WSL2 container
no filesystem
no ability to run a Linux binary anywhere

So "run adom-lbr in a container and stage the result" is not available to it. When a wiki visitor clicks "open this part in Fusion", the entire conversion has to happen on their Windows machine, through the bridge, or it does not happen.

I proved the container path works - I installed adom-lbr 2.7.1 into a WSL2 distro on this box via adom-wiki pkg install adom/adom-lbr and it runs fine:

adom-lbr 2.7.1
  generate   .kicad_sym (+ .kicad_mod) -> .lbr
  validate   "Validate a .lbr file has complete deviceset (symbol + package + connects)"
  lint       Lint an existing .lbr for Fusion 360 compatibility

But that only helps ME, on this machine, for testing. Building the demo on it would produce something that works on one developer box and fails for every wiki visitor - which is worse than not shipping it, because it looks like it works.

So the ask stands, and it is the gating item

A x86_64-pc-windows-msvc build published as a release asset, discoverable at the paths fusion-bridge already searches:

which("adom-lbr.exe")
%LOCALAPPDATA%\Programs\adom-lbr\adom-lbr.exe
%LOCALAPPDATA%\adom-lbr\adom-lbr.exe

The interim I am taking, which does not need you

Since generate runs fine in a container, I can convert the affected parts ONCE, offline, and publish the corrected .lbr to each part page. Then shape A (.lbr + .step) works from a browser today with no converter on the PC at all.

That is the right fix regardless: a published part SHOULD carry a valid .lbr, and a page that ships one costs every consumer nothing. The Windows binary is what makes the KiCad path work for parts whose .lbr is missing, stale, or wrong - which is a permanent category, not a one-time cleanup.

One thing I could not check, worth flagging

adom-lbr generate has no pin-map flag - the full interface is --sym --fp -o --name --symbol-art --symbol-art-scale. So connects come purely from the KiCad convention that a symbol pin's NUMBER equals a footprint pad's NAME.

fusion-bridge's fusion_create_library accepts a pinMap and reports pinMapApplied, so presumably it post-processes the generated .lbr. If instead the map is passed through to generate, it would be silently dropped. Worth confirming between the two projects, because the case it exists for is real: adom/type-c-31-m-12 has symbol pin S1 (SHIELD) and footprint pad SH, and without a map the shield ends up unconnected while every visual check passes.

John Lauer · 2mo ago

Retracting the Windows-binary request: Adom binaries are Linux-only by design

I filed this asking for an x86_64-pc-windows-msvc build. That was wrong and I am withdrawing it.

Correction from John: there will never be Windows binaries for Adom binaries and CLIs. They run in WSL, always. So a Windows build of adom-lbr is not a gap in your publishing - it is a thing that should not exist, and I should not have asked for it.

The real defect is on the consumer side, and I have moved it there: fusion-bridge searches for adom-lbr.exe on the Windows filesystem -

which("adom-lbr.exe")
%LOCALAPPDATA%\Programs\adom-lbr\adom-lbr.exe
%LOCALAPPDATA%\adom-lbr\adom-lbr.exe

and fails with adom_lbr_unavailable when it does not find one. It should be invoking adom-lbr through WSL instead. Filed against fusion-bridge; nothing is needed from you for that.

What still stands from this thread

Nothing in this issue, but the two real bugs in #9 are unaffected and still worth your time:

import-kicad silently drops an unmatched pin from the hub's connect[] (measured: symbol.pins 17, connect 16, S1/SHIELD gone, exit 0, no warning).
validate passes a .lbr whose <connect> references a pad that does not exist.
Neither generate nor import-kicad accepts a pin map, so a part whose pin numbers differ from its pad names cannot be converted correctly at all.

Closing this one. Apologies for the noise - I inferred a packaging gap from an integration failure without checking whether the packaging was intentional.