When symlinking a `.def` to a target without `.def` suffix, file can't be loaded.

[mithro]

I have a .def file at /build/cas/a97/a971575b8189215e2db9f3e6fbfa26b6254f140191604c8194307564d724f936_010e8e6d and a symlink to that file verilog_counter-asap7-sc7p5t_rev28_lvt-place_and_route_detail_routed.def -> /build/cas/a97/a971575b8189215e2db9f3e6fbfa26b6254f140191604c8194307564d724f936_010e8e6d

When I try to open the file with the ly.read('verilog_counter-asap7-sc7p5t_rev28_lvt-place_and_route_detail_routed.def') I get RuntimeError: Stream has unknown format: /build/cas/a97/a971575b8189215e2db9f3e6fbfa26b6254f140191604c8194307564d724f936_010e8e6d in Layout.read

If I replace the symlink with a file containing the same as /build/cas/a97/a971575b8189215e2db9f3e6fbfa26b6254f140191604c8194307564d724f936_010e8e6d, KLayout then is able to read the file.

I think this is because something is resolving the symlink and the loading depends on the file extension to detect the file format?

[klayoutmatthias]

Yes, the name is resolved absolutely as the path is required as a base path for the LEF files. This also implies that LEF files belonging to the DEF file (i.e. read "together" with the DEF file) need to be placed at the target location the DEF file.

Basically, the format detection could happen on the original file, but that may need some deeper code rework I'm afraid. Or I simply drop following the symlink. That will change the mentioned behavior for localizing the LEF files, but maybe that is acceptable.

Matthias

[mithro]

On the topic of finding includes / relative files.

We use a build system (Remote Build Engine with blaze / bazel) which stores the actual files in a "Content Addressable Storage" (CAS). It then builds a tree of directories with all files being symlinks into the CAS system.

In our setup, we would expect relative files to be found relative to the filenames given to KLayout and not relative to the file names found on the CAS (as they won't have the expected names).

I could see someone arguing that the symlink should be first resolved and then files should be found relative to the resolved file.

Maybe the only solution for that would be to first check relative to the provided file path and then if that fails check relative to the resolved path?

---

Maybe the same should happen with using the file detection? IE First check the provided filename and if that doesn't work, resolve the symlink and try with that filename?