bazel: add bazelisk run //:cmake — dependency prefix for plain CMake builds

[oharboe]

Stacked on #10812 (the diff shows both until that merges; review this PR from the `bazel: add bazelisk run //:cmake commit).

Problem

Building OpenROAD with CMake requires etc/DependencyInstaller.sh: sudo, distro-specific package lists, and from-source builds of boost, or-tools, abseil, swig, bison, spdlog and more into /usr/local or ~/.local. The bazel module graph already carries every one of those dependencies at pinned versions and builds them hermetically.

Change

A bazelisk run //:cmake target that materializes those dependencies into <workspace>/deps for a plain CMake workflow:

bazelisk run //:cmake
cmake -DCMAKE_TOOLCHAIN_FILE=deps/toolchain.cmake -B build .
cmake --build build -j$(nproc)

deps/ (~1 GB, gitignored, regenerated on every run) contains:

• the merged header tree and every static archive of the dependency closure (boost 1.89, abseil, or-tools 9.15 with scip/highs/glpk/soplex/bliss/protobuf, spdlog, fmt, eigen, lemon, cudd, zlib, yaml-cpp, googletest, openmp),
• the build tools: swig 4.3.0, bison 3.3.2, flex 2.6.4,
• Tcl 9 (archive, headers, and its script library at lib/tcl9.0),
• a hermetic CPython 3.13 (interpreter, headers, libpython, stdlib),
• the hermetic clang/libc++ toolchain from bazel: switch C++ toolchain to hermetic-llvm; add etc/bazel-hermetic #10812 behind generated bin/cc/bin/c++ wrappers, and a toolchain.cmake that points CMake at all of the above.

Host requirements: bazelisk, cmake ≥ 3.16, ninja or make, git, bash. No sudo, no compiler packages, nothing written outside the workspace. This is additive and opt-in: DependencyInstaller.sh/Build.sh are untouched, and the CMake workflow afterwards is plain cmake — bazel is only the provisioning tool.

Mechanics

• Compiler/linker flags are extracted from the resolved C++ toolchain at analysis time (cc_common.get_memory_inefficient_command_line, the rules_foreign_cc technique) and rewritten to relocatable paths, so the wrappers cannot drift from the bazel toolchain when the llvm module is bumped. Build-type flags (-O, -g, -std=, warnings) are left to CMake.
• Archives are linked through a single interface target carrying a --start-group pool; order becomes irrelevant and the absl/or-tools/scip/protobuf interdependencies need no per-package attribution. The seven or-tools alwayslink archives are --whole-archived.
• Package config shims (Boost, absl, ortools, spdlog, fmt, Eigen3, LEMON, GTest, yaml-cpp) live in cmake-deps/shims/; TCL, ZLIB, CUDD, SWIG, BISON, FLEX, Python3, OpenMP are steered through their existing Find modules by cache variables in toolchain.cmake. Dependency versions are parsed from MODULE.bazel into a generated deps-versions.cmake.
• The multiplexed ~190 MB LLVM binary is staged once; the tool names are recreated as relative symlinks.

One change to existing CMake files: src/gui/CMakeLists.txt now only requires OpenGL when the GUI is actually built (Qt5_FOUND AND BUILD_GUI); OpenGL::GL is only referenced inside that branch, and the unconditional find_package(OpenGL REQUIRED) made GUI-less hosts install OpenGL headers for a CLI build.

Scope

• Linux x86_64. macOS needs a platform-conditional pool file (ld64 has no --start-group/--whole-archive) and a different C++ runtime story; deliberately a follow-up.
• The GUI is not part of the prefix: host Qt5 is a libstdc++ build and cannot link against libc++ archives. toolchain.cmake sets BUILD_GUI=OFF; the build degrades to CLI exactly like a host without Qt.
• The produced binary is a clang/libc++ build, matching the bazel build.

Verification

On Ubuntu (cmake 4.2.3, ninja), from a clean checkout:

$ bazelisk run //:cmake
$ cmake -DCMAKE_TOOLCHAIN_FILE=deps/toolchain.cmake -G Ninja -B build .
-- Configuring done (8.1s)
$ cmake --build build -j8
[3239/3239] Linking CXX executable ...
$ ldd build/bin/openroad
        libdl / libpthread / libm / librt / libc / libutil (host glibc)
        libpython3.13.so.1.0 => .../deps/python/lib/libpython3.13.so.1.0

• Every Found ... in the configure log resolves under deps/ (TCL, SWIG 4.3.0, Boost 1.89.0, absl, GTest 1.17.0, Python3 3.13.11 Development+Embed, ZLIB 1.3.1, spdlog 1.15.1, BISON 3.3.2, FLEX 2.6.4, CUDD, OpenMP 5.1, OR-Tools 9.15, Eigen3, LEMON, yaml-cpp, fmt). CMakeCache audit: nothing resolved from /usr besides bash, git and optional Doxygen.
• Zero compile errors and zero toolchain-flag warnings across the 3239-step build.
• Smoke: openroad -version; a utl tcl regression (logger_redirection.tcl); from openroad import Tech via -python; a gtest unit binary (TestMetrics) — all pass with TCL_LIBRARY=deps/lib/tcl9.0 PYTHONHOME=deps/python.
• bazelisk run //:cmake re-runs are idempotent (deps/ wiped and recreated; a stamp file guards against deleting a foreign directory).
• bazelisk build //:openroad analysis and bazelisk test //:lint_test unaffected.

Type of Change

• New feature (build infrastructure)

• I have verified that the local build succeeds

• My code follows the repository's formatting guidelines

• I have signed my commits (DCO).

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to materialize OpenROAD's third-party dependencies into a local deps/ folder, enabling developers to build OpenROAD using plain CMake on Linux x86_64 without running DependencyInstaller.sh or installing host compilers. This is achieved via a new Bazel rule (cmake_deps_bundle) that packages headers, static archives, the hermetic clang toolchain, and config shims into a relocatable prefix, alongside a wrapper script (etc/bazel) to run Bazel in a pruned environment. The review feedback focuses on improving robustness, including safeguarding the destination path in materialize.sh when run outside of Bazel, avoiding fragile Bzlmod canonical repository names (like googletest+) by copying archives to stable paths, enhancing shell-quoting robustness for toolchain flags containing literal $ characters, and adopting idiomatic with open(...) blocks in Python scripts to prevent unclosed file descriptors.

[oharboe]

@maliberty @hzeller What do you think about this idea?

Get CMake users onto bazel dependencies without forcing them to drink the Bazel cool-aid, just address the DependencyInstaller.sh hell + move onto a single source of truth for dependencies.

Mostly, per Matt, OpenROAD developers sit in their favorite IDE, fix+compile+debug, repeat..

The Bazel IDE experience isn't as good always. As an example, the IDE, intellisense and build is fighting over the same bazel-* folders, single threading them.

[oharboe]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to materialize OpenROAD's third-party dependencies and a hermetic LLVM toolchain into a local deps/ folder, enabling plain CMake builds without requiring host compilers or global dependency installers. It replaces toolchains_llvm with hermetic-llvm (llvm), updates macOS requirements, and adds a pruned wrapper script (etc/bazel) to run Bazel hermetically. Feedback on these changes suggests making the MODULE.bazel version parser in assemble_bundle.py more robust against reformatting, avoiding global injection of preprocessor defines via compiler wrappers to prevent macro namespace pollution, and adding a fallback in etc/bazel to handle non-bazelisk wrapper scripts gracefully instead of failing unconditionally.