Layers initialization failure

charavan

Greetings,

Wanted to bring to your attention that when a KLayout "tech" folder has the below structure:

tech/
test.lyp -> 2/test.lyp
test.lyt -> 1/test.lyt

It fails to initialize the Layers with the corresponding message:

I understand that KLayout assumes that .lyt and .lyp files should be in the same directory but when this directory is managed by a Design Management Tool it can happen that these files reside in different folders.

Matthias

Hi @charavan,

So you mean that "test.lyp" is actually a symbolic link? If by Design Management Tool you mean Clearcase, it is not.

The ".lyp" file can reside somewhere else than ".lyt", but the path is resolved relative to ".lyt".

Matthias

charavan

Hello Matthias,

The problem occurs when the files are checked-in, not when checked-out. When checked-in, the “tech/*.{lyt,lyp}” files are symbolic links, and the actual files they point to can happen to reside in different locations, when either file has been updated.

In the example above, when you resolve the lyt path, the base_path equals “tech/1” whereas the lyp file exists under “tech/2”, so KLayout fails to load it. Thus, in this particular scenario, the fact that you always resolved lyp relative to lyt may cause layers initialization to fail.

Matthias

So you're implying that the scheme works, if the files are real files, but not if the files are symbolic links?

That may be true, because the effective location of ".lyt" then is somewhere where ".lyp" is not seen. But I recall that using the effective location was an explicit request from a different party who wanted to put their technology package into a different place as a whole.

So what am I supposed to do?

BTW: modern configuration management systems don't do this symbolic link thing. KLayout is not the only tool that needs to decide what to do with them. I wonder why you are using this system? I bet it cases trouble in other places as well.

Matthias

dick_freebird

As long as full path works, I'm good.

charavan

Hi Matthias,

I think one viable solution would be to calculate the base path prior resolving possible symbolic links.

Assuming we have the below directory structure as part of $KLAYOUT_PATH,

klayout/tech
test.lyp -> 2/test.lyp
test.lyt -> 1/test.lyt

the base path will be klayout/tech instead of klayout/tech/1. Then, you should be able to safely resolve both lyp/lyp and get their real files.

The behavior was observed in another party who had the KLayout tech folder design managed. I cannot recall the software used, but it was one of the “known ones” and certainly, it was not an old version. My understanding is that they have updated the revision of the lyp file, and when they checked it in, the real file is stored in a different physical location (/1/ -> /2/)

In any case, you don’t’ have to necessarily do something about it, especially if you think it will break things elsewhere. And certainly, we don’t want to change the requirement of having lyp/lyt co-exist under the same folder. However, maybe changing the way you calculate the base path would accommodate this scenario too.

Thank you.

Matthias

Hi @charavan,

that raises the question what symbolic links and what not. The original problem was that the whole folder itself was a symbolic link, like

klayout -> somewhere/klayout

Now klayout/tech/tech.lyt would be (klayout->somewhere/klayout)/tech. That path is then not to be realpath'd while klayout/tech/(tech.lyp->1/tech.lyp) should be?

That feels inconsistent. Resolve symlinks unless they are the last component of a path?

No modern versioning system like git, but also older ones such as ClearCase, Perforce, Subversion or CSV use symbolic links. Likely because symbolic links are not available on Windows for example. Some Linux-rooted package managers like nvm or nix use symbolic links to build a link tree with specific program versions. But that would be more consistent with having a link tree like

klayout/tech -> klayout/tech/1

klayout/tech/1/tech.lyp
klayout/tech/1/tech.lyt

so the base path would work as is.

Let me know if you more details about that specific versioning system. Currently, that requirement raises too many questions for my taste without providing some evident benefit for a larger user community.

Matthias

dick_freebird

Maybe if every layer of the path-resolution was "bite
sized" as a shall variable, the user might find a way
do this abstraction.

Personally I like full hard paths nobody can mess
with, but I am not subject to CAD management
or its dictates.

KLAYOUT_TECH_HOME=
KLAYOUT_TECHNOLOGY=
...

$KLAYOUT_TECH_HOME/$KLAYOUT_TECHNOLOGY/...

Some shell script intervening, executed by the klayoutrc
could be even more sophisto? Clever boys might make
their own startup which a project-start-script could
preload. This was always how we set up Brand X, our
corporate project management overlay would be
invoked from a local shell script (made one time at
project setup) which left shell vars all set up like
bowling pins for the "real" initalization chain.

Now let me dispense a little brain-worm for the devs.

Day is coming, for multi-technology layouts (2.5DIC
heterointegration) comprising plural chips. Library
structure will need to "stick to the bound tech" (per
library) and could be N libraries. Big Iron is on it.
Capability to handle module-level products and
MCM "IC-form" products might be better than a PCB-
centered tool.

This kind of thing will only get tougher for the "single
tech" paradigm.