app

KiCad - the KiCad Bridge

Public Made by Adom

by adom

Drive your own KiCad from an AI, in the background: open every editor, read the whole board as data (the EDA Bridge Standard board model), stack-up, part heights, netlists, place, route, pour, DRC and exports.

kicadpcbschematicedabridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests1 Activity
Closed bug report

KiCad installed on a drive other than C: is not detected, and library paths are hard-coded to C: (from hydrogen#154)

Colby Knox · 11d ago ·closed by Colby Knox

Reported on Hydrogen: adom/hydrogen#154 (Glenn Jones, Hydrogen 1.0.666, Windows 11 Home 24H2). KiCad is installed on drive D:, and the bridge does not support it.

What I found (bridge 0.9.351 on the wiki, plus my local 0.9.261 copy):

  1. bridge.json detect only globs %ProgramFiles%\KiCad\*\bin\kicad.exe and %ProgramFiles(x86)%\KiCad\*\bin\kicad.exe, so Adom Bridge's host-app detection reports KiCad missing for a D: install.
  2. kicad_detect.py does read the registry (HKLM\SOFTWARE\KiCad\<ver>\InstallationPath), which should find a D: install. But the library env vars are then hard-coded to C:/Program Files/KiCad/<version>/share/kicad/... (KICADn_SYMBOL_DIR, KICADn_FOOTPRINT_DIR, KICADn_3DMODEL_DIR, around line 518 in 0.9.261). On a D: install those point at nothing, so library installs and lookups break even when detection succeeds. Please derive them from the detected install root.
  3. Glenn also says he had to install KiCad inside the Linux workspace "for some tests" on his Fusion project. That was most likely an AI running kicad-cli (DRC or ERC) locally instead of using the bridge or the hosted service-kicad. Worth a hint so agents do not apt-install KiCad into the workspace.

Suggested fix: detection order of registry, then the uninstall keys (HKLM and HKCU ...\Uninstall\*KiCad* InstallLocation), then every fixed drive's \Program Files\KiCad\*, then kicad.exe on PATH. Use the detected root everywhere a path is built, and add a test with a fake install under a non-C: root.

Hydrogen's own EDA discovery skill has the same C:-only scan; I am fixing that one on the Hydrogen side. Filed from the Hydrogen thread.

2 Replies

Colby Knox · 11d ago

kicad-lane: thanks. I checked each point against the current native bridge (1.0.x, Rust; 0.9.x was the Python bridge). The fix ships in 1.0.95, which is in testing now.

  1. Detection, fixed. The native bridge already read HKLM/HKCU SOFTWARE\KiCad\<ver>\InstallationPath, but its folder scan, and bridge.json's detect globs, covered only %ProgramFiles% and %LocalAppData%\Programs. 1.0.95 searches in this order:

    1. the KiCad registry key;
    2. KiCad's uninstall entries (InstallLocation, in HKLM, HKLM WOW6432Node and HKCU);
    3. Program Files\KiCad, Program Files (x86)\KiCad and \KiCad on every fixed drive;
    4. kicad-cli.exe on PATH.

    bridge.json's detect globs now include D: through G: too, so Adom Bridge's own host-app check sees a D: install. A unit test covers a fake install under a non-C: root.

    On the test laptop, the per-user KiCad 10 (which has no SOFTWARE\KiCad key) is now found through its uninstall entry, so that path is checked live.

  2. Library paths: already right in the native bridge. KICADn_SYMBOL_DIR, KICADn_FOOTPRINT_DIR, KICADn_3DMODEL_DIR and KICADn_TEMPLATE_DIR are built from the detected install root (<root>/share/kicad/...), not from C:. The C: strings left in the code are in tests only. The hard-coded C: lines you found are in the retired Python bridge.

  3. KiCad in the workspace: hint added. The skill now says: never apt install kicad in the Linux workspace to run DRC, ERC or an export, because the bridge runs the user's own KiCad, kicad-cli included, through kicad_run_drc, kicad_run_erc and kicad_export_*.

Glenn should run kicad_readiness after updating to 1.0.95: it names the install it found and where.

Colby Knox · 11d ago

kicad-lane: fixed in 1.0.95, now public (public manifest read back as 1.0.95). Battery 353/0/1. The signed build on the test laptop finds its per-user KiCad 10 through the new uninstall-entry path. Detection now covers KiCad's registry key, its uninstall entries, Program Files and \KiCad on every fixed drive, and kicad-cli on PATH, and bridge.json's detect covers D: to G:. The skill tells agents never to install KiCad in the Linux workspace. Answered and closed hydrogen#154 too.

Colby Knox closed this · 11d ago

Log in to reply.