Question triplicated, because the root cause of this problem is the existence of a competence boundary between caravan, xschem, and sky130 maintainers.

Open PDKs installs all those libraries in /usr/share/pdk . The caravel_user_project_analog github project was made with this in mind, I guess. Any other installation without this path won't work without modifications.

xschem can work with variables for paths, but ngspice doesn't. But the example analog user project design was made before path variables were implemented in xschem, which is probably the root of the issue.

@Luis Henrique Rodovalho in Xschem schematics never contain absolute paths, any component instance is referenced by a name, it can be just

inv.sym

or

cmoslib/inv.sym

or

pdk_45nm/cmoslib/inv.sym

. It is up to the project manager to set up a consistent structure for the project. Xschem initialization file (xschemrc) defines a list of paths:

set XSCHEM_LIBRARY_PATH /path/a:/path/b:/path/c

if schematic references a component as

cmoslib/inv.sym

the actual location in the filesystem is found by searching the XSCHEM_LIBRARY_PATH, so one of:

/path/a/cmoslib/inv.sym

, or

/path/b/cmoslib/inv.sym

, or

/path/c/cmoslib/inv.sym

The first succesfull match is taken. If your

cmoslib

is upgraded, say to

cmoslib2

, you can use a unix symlink

cmoslib->cmoslib2

and have your design automatically use the new library. Or you can search and replace all occurrences of cmoslib/ to cmoslib2/ in xschem schematics. (xschem files are just plain ascii, you don't need fancy tools to rename referenced libraries). Again this is a project management decision. Also note that since xschemrc is a tcl file you can use variables:

set XSCHEM_LIBRARY_PATH ${PDK_ROOT}/xschem/:.....

to use a tcl global variable, or

set XSCHEM_LIBRARY_PATH $env(PDK_ROOT)/xschem/:.....

to use a shell variable.