One or many OpenROAD binaries

[oharboe]

I’m tossing around a thought experiment about OpenROAD’s single binary, which lumps batch, headless, and GUI modes together with a mess of distro-specific dependencies like Qt and readline. This is tricky to reproduce in Bazel. This could be a sign that we should reconsider our approach.

What if we split it into tailored binaries? I’m not sold, but it’s worth thinking about, especially since cramming everything into Bazel feels like fighting Linux’s nature. CMake and Python wheels might be better for distro dependencies.

Here’s the idea on various binaries we could build:

• openroad: Full-featured with Qt and readline, still works for batch.
• openroad-batch: Lean, batch-only, maybe statically linked for no dependencies.
• openroad-floorplan, openroad-place, etc.: Stage-specific, lightweight binaries. It would be neat if bazel-orfs re-ran ORFS tests from e.g. placement if openroad-place was the stage that changed.
• openroad.so: Shared library with C++ interface. A C only interface I think would be tough, but it could lead to having to build one openroad.so for each ABI, even if there are no other dependencies on distribution. I read very briefly on python wheels and stable Linux ABIs. Lots of snags and details here and guidance from someone who's done it before would save everybody time and agony, I'm sure.

Builds:

• openroad-batch, openroad.so: Bazel for clean, minimal builds.
• openroad: CMake to handle Qt and readline, linking to openroad.so.
• openroad-python.so: Python wheel for pip bindings.

[maliberty]

I expect most people using a batch version will need a GUI to inspect the results so I'm not sure how much benefit that split gives.

Stage-specific, lightweight binaries are not a good idea imo. It is trying to fit the tool to Bazel rather than the user.

openroad.so is a goal but not a high priority one.

[gadfort]

I would prefer one binary, even in batch mode we support taking screenshots of the design (which requires the GUI), splitting out the binaries by stage seems like a bad idea.