[oharboe]

Follow-up to #4712, and a draft until it merges: the first commit here is #4712's.

KLayout's own Python module, pip install klayout, writes the GDS file. It is a prebuilt wheel, with no Qt and nothing to compile, for Python 3.10 and up on Linux (x86_64 and aarch64, glibc 2.27 and up) and macOS. With it, the installer no longer installs the KLayout application, and the flow writes a real GDS file wherever its Python packages are installed.

sky130hd lb_32x128, make do-gds	KLayout Python module 0.30.12	KLayout application 0.30.0
layout	identical (LayoutDiff, 12 cells)	identical
bytes that differ	26, the GDS timestamps
wall time, peak memory (one run)	0.34 s, 101 MB	1.36 s, 403 MB

Installation, simpler

etc/DependencyInstaller.sh loses its KLayout install for every OS, and the module comes in with the other Python packages from etc/requirements-common_lock.txt. The lock already needs Python 3.10, so this adds no new requirement on the Python version. Deleted:

• klayoutVersion and the version-check-and-reinstall logic, written three times (CentOS 7, CentOS 8, Rocky Linux 9) around klayout.org RPMs.
• On Ubuntu x86_64: the klayout.org .deb download, its md5 table per release, and the "Unsupported Ubuntu version" exit, so KLayout's packaging no longer limits which Ubuntu releases the installer supports.
• On Ubuntu aarch64: the build of KLayout from source, with its Qt, Ruby and libgit2 build dependencies, the slowest step of a fresh aarch64 install.
• klayout from apt on rodete, and the Homebrew cask on macOS.
• env.sh: the KLayout.app PATH entry on macOS.
• flow/scripts/variables.mk: the lookup of a KLayout in tools/install/klayout, which nothing installs.
• docs/user/BuildWithPrebuilt.md: the KLayout version note and the LD_LIBRARY_PATH line for a KLayout built from source.

127 lines deleted from the installer, env.sh, variables.mk and the docs, 13 added. Added: klayout in etc/requirements-common.in, pinned at 0.30.12 in the lock, the version the installer installed until now.

What still needs the KLayout application

make drc, make lvs, the gallery and the viewers. The DRC and LVS rule decks are scripts in KLayout's Ruby-based DSL, which the Python module does not include. None of them runs in the default make, nor in CI's finish metadata. Those who run them install KLayout themselves; the docs say where.

Commits

1. klayout.sh: without KLayout, stream out an empty GDS file and warn #4712: without KLayout, the GDS file is written empty with a warning.
2. def2stream.py has a command line and is run by PYTHON_EXE. It takes the first KLayout it finds: the Python module in-process, then a KLayout executable (KLAYOUT_CMD or klayout on PATH) run as before, then neither, and the file is written empty with klayout.sh: without KLayout, stream out an empty GDS file and warn #4712's warning. The warning moves from klayout.sh into def2stream.py, and klayout.sh goes back to running the KLayout application only.
3. The installer, env.sh, variables.mk, the requirements and the docs, as above.

Tests

• flow/test/test_def2stream.py checks each of the three choices: the module gets the arguments; an executable on PATH gets them as -rd variables, with the environment, and its exit status is returned; without either, the file is written empty with the warning. Only an absent KLayout is let through: a KLAYOUT_CMD naming no file, or an executable that fails -v, is an error and writes no file.
• flow/test/test_klayout_sh.py keeps klayout.sh: without KLayout, stream out an empty GDS file and warn #4712's checks that DRC and the viewer stop without KLayout, and that an installed KLayout gets the call unchanged.
• End to end, make do-gds on sky130hd lb_32x128 once for each choice: the module and the application wrote the layouts in the table above, and with neither the file was written empty with the warning.
• Not run: the wrapped-macro merge (WRAP_LEFS), which only gf12 designs use. It calls the same script with the same arguments as before.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request refactors the flow to make KLayout an optional dependency by utilizing the klayout Python module for GDS/OAS stream generation, falling back to mocking (writing an empty file with a warning) when KLayout is entirely missing. It updates dependency installers, Makefiles, and documentation to reflect this change, and adds corresponding unit tests. The review feedback correctly identifies a critical issue in flow/util/def2stream.py where a subprocess version check could cause an unnecessary hard failure, and points out that the custom environment dictionary is not being forwarded to the spawned subprocesses.

[oharboe]

@maliberty @eder-matheus @vvbandeira TL;DR klayout has been a thorny dependency and it confuses users

This is intended to prune as much as possible from ORFS install scripts, etc. while giving each use-case the least chafing experience.

We try PyPi klayout first, then local and finally we write an empty .gds file and a warning.

The full klayout install is still needed for make lvs/drc and gallery, but I think those are out of the way for most users and PyPi klayout doesn't have ruby, so there's nothing for it, full klayout install is needed. This would be solved by documentation, this is an out of the way use-case you have to install klayout yourself.

[openroad-ci]

🔍 QoR check

Metrics reflect the PR merge build — i.e. what will land on the target branch.

Commit e0a9659 · Jenkins build #2 · Baseline: build · View build on dashboard

62 design(s) checked — 0 with regression(s), 1 without a comparable baseline.