<@U020J2W6Q84> Is there any way to tell OpenLane2 ...
# openlane-2
m
@donn Is there any way to tell OpenLane2 to NOT use local tools? This could be an issue that many people mess up. For example, I am going to teach a class where students will need a version of KLayout installed (the one in OL2 is not sufficient since it doesn't have Qt and therefore cannot use the Sky130 LVS menus). However, they will need to uninstall KLayout when they want to use OL2 otherwise they risk a problem. (I just ran into this yesterday with the 2.2.9 -> 2.3.0 update.)
OR: Is there a way to issue a WARNING that it is using a local version? This should be the minimum...
Is it even true that it uses locally installed tools? I see this in the OL2 issues, and I had an issue with a locally installed klayout python module, but if I run Nix or Docker, it seems to have the non-locally installed version.
d
Tools, not Python modules. KLayout is its own nightmare.
Oh, you meant Qtbindings
It seems that it didn't even pick up a local tool though... I installed KLayout 0.29.10 and it still found 0.29.4 in Nix and Docker
d
well, it all depends on the values of
PATH
and
PYTHONPATH
, which I really can't control much other than to discard's the user's own `PATH`/`PYTHONPATH` at all times but that would break, say, plugins for proprietary tools
A surefire no-nonsense workaround for this is just to use
openlane --dockerized
, OpenLane 1 style
(Also I can just build KLayout with qtbindings if you want)
m
The last would be ideal! Ohhh, I see, the nix path is inserted before /usr/bin in my PATH, so it found the Nix copy rather than the local copy.
d
OpenLane 2.3.1 should be pushed with a qtbinding-enabled version of KLayout. However, that increases the build artifact size from ~70 MB to a whopping ~270 MB.
m
Oof, yeah.
I see a use for it but understand if it doesn't deserve the image increase cost
d
It's already pushed. We may have to revisit this in the future but for now I want to make sure you have what you need.