Klayout Install

[Liora Putcha]

Linuxpackages are signed with the GPG public key (Matthias Koefferlein).

Windows packages are signed with a code signing certificate (issued by Certum) as: "Open Source Developer, Matthias Koefferlein".

For the Windows platform, a self-extracting installer binary is available.To install KLayout using the installer, download the executable and run it.It will install the binaries at the target location, which can be selected in the installer user interface. In addition, it will create three KLayout shortcuts in the "Programs" section of the start menu. It will also register itself as handler for file types ".gds" and ".oas" and other related formats.

If the installer is executed from a normal user account, it will install itself for that user only. No particular rights arerequired in this case. If started with administrator rights, it will install itself for all users.

Alternatively, a zip archive is provided that contains all the required executables and DLLs. It is possible to run KLayout directly from these files after extracting the archive.The KLayout executable is "klayout_app.exe".Using the .zip archive is the recommended way to try KLayout without contaminating the system.

For CentOS and OpenSuSE systems, RPM packages (.rpm) are provided on the download page. For Ubuntu, Debianpackages (.deb) are supplied. Only 64bit systems are supported, because 32bit is about to vanish now.All packages are signed with the GPG public key (Matthias Koefferlein).

The "klayout-bits4msvc2017" project ( _bits4msvc2017) targets towards providing a binary distribution for this purpose. See the release notes there for download links. Download the .zip archive from there and unpack it to some folder, e.g. "c:\klayout-bits".

The build script needs the path to this package. "qmake" and (for obtaining the build version) "git" should be in the path. If qmake is not in the path, you can use "build.bat -qmake ..." to specify qmake's path.

The 3rd party bits kit can also be used to build the Python standalone package on setuptools. Specify the full path to the 3rd party package up to the compiler and architecture. On 64bit with the bits package installed in "c:\klayout-bits" the build call is this:

MSYS2 has three target systems: "mingw64" as a build environment for 64bit applications, "mingw32" for 32bit applications and "msys2" for build runtime. A variety of packages need to installed using the "pacman" package manager or MSYS2.To install these packages, open a MSYS2 shell and install the packages with pacman:

After the build finished, you will find the binary in "bin-release". To run it, stay in the MINGW 64bit shell.With Python3 you will initially see an error indicating that Python cannot find the encoding librariy.This is because the Python path is not set yet.You can do so by setting the "KLAYOUT_PYTHONPATH" environment variable. However it is easierto create a file KLayout reads to set the Python path:

A script is provided that integrates the build and packaging steps and generates the installer using the Nullsoft install system (NSIS). This script is "deploy-win-mingw.sh" from the "scripts" directory. It requires MSYS2, the packages mentioned above and the NSIS installer system ( -dev.github.io/).

I'm on a freshly upgraded Fedora Core 30 system. So I figured I needed to build my ow copy of klayout from source. I used the klayout-0.25.9.gz tarball, which bombed when trying to include stdlib.h. I'm guessing I don't have the right libraries installed. Is there a summary of the required libraries/supporting packages available?

I spent a little time downloading and trying the klayout build with different package versions. Things seemed to generally work, but I ended up with the error as shown below. Is this still a package version issue encountered during the make? Or am I still nissing something?

From the log it looks like you're using Qt5's qmake. Please check with "qmake -v". If that is some 5.x.y version, you need to install Qt5 headers too (usually qmake and the headers come with the same package).

Still no luck. It looks like I have both the qt and qt5 libraries installed, as well as gcc and g++. Also, I did not find a qmake on the system; but a qmake-qt4 and qmake-qt5. I tried making klayout using:

Sorry to be a bother. I've never used Docker, and will check it out. I agree... something is boogered up with my FC30 installation. Hopefully the use of Docker will not only lead to a successful klayout make, but point to the problems with my system as well.

It's not a RPM, but the binaries produced for version 0.26. You might be able to run them when you set LD_LIBRARY_PATH to the absolute path where you unpacked the tar file (I assume it will find the Qt libraries without this).

i was trying to install Klayout in Ubuntu 21.04, I faced quite some problem in installing it using the .deb file in the download section of the file.

This is do to some missing dependencies that have been removed in the public repositories ? in particular the Qt5 and the libpython3.8 .

I managed to solve the problem installing manually the Qt5 dependencies and I was left with the libpython3.8 that I have no idea of how to solve since the library is already installed but is the 3.9 version that comes as default with the distro.

The final solution was to install the software using a simple " sudo apt install klayout".

The software got installed but at the running moment a warning was displayed regarding a Wayland related problem and the software didn't run.

I then logout and log in using gnome on xorg.

Now the software works fine, but I have to use the xorg environment.

Did someone experience similar issues with the installation ? hope my description can help someone with the same problem. Would be also interesting to know what is missing in the new ubuntu that causes so much trouble

I would like to see, somewhere in the release collateral,

a complete list of all packages required (with version)

or better yet, some "pull scripts" that would ensure that

the dependencies are all in place or make it so. Like

apt for Ubuntu, rpm for RHEL, ??? Rather than waiting

for compile-fail and wading through the barf, why not

get in front of it?

Some of these distributions are too fast-revving to

rely on, and some users (like me) are not really good

at compiling if anything anomalous happens. Such

as some distro-monger deciding you should be on a

different version, without asking.

I don't know if qt5ct is the right way to do it, but I was not able to find anything useful otherwise. The "-without-qtbinding" trick is to speed up the build process - unless you need Qt5 in your scripts, you can skip the Qt5 binding with this option. This also reduces the dependencies.

I already use homebrew. Are you saying I can effectively do "brew install klayout" (or whatever) and I'll end up with what I'm after? I'm not really a programming person but I sure know how to follow clear instructions if they're written down :-). I've heard of GitHub, and it certainly sounds like a place I'd hang out at, but I wouldn't know what to do when I got there...

Thanks guys - great inputs! I haven't actually purchased my Apple Silicon Mac yet, I'm just going through a bunch of key software beforehand to make sure everything will go smoothly. I've since found out that an ancient but critical PC program (for which I have long since lost the installation discs) that I use within a Windows 11 VM can not be migrated to Windows 11 ARM so that's kind of derailed me at the moment. In fact, any Intel Windows VM can't be migrated to an ARM Windows VM :-(

Hi,

Recently I wrote a Python script for viewing layouts as 3D models in OpenSCAD. Initially it was just for fun but then I realized it's also quite helpful for debugging. Therefore I thought I'd best package it as a Salt module.

An automated option (I have not tried myself) to take care of this is using an autorun script inside the module. Let this script run once (use your own configuration variable to mark it run). In this script you can try to pull the package from PyPI. But I suspect many side effects and error handling is crucial. Otherwise there is risk to damage a user's installation.

If somebody would like to use Blender instead of OpenSCAD, let me know. I started experimenting and I would be motivated to push the project if somebody is interested.

Blender would be useful for good-looking renderings and illustrations.

Note:

The dependencies are correctly installed under C:\Program Files (x86)\Python36-32\ but the macro environment does not see this package location. Manually adding the dependencies to

C:\Users[user-name]\AppData\Roaming\KLayout.python-paths.txt

did not resolve the issue.

KLayout comes with it's own Python interpreter and does not take any interpreter provided by the system. This leads to manifold issues usually due to incompatibilities of the binary APIs. And KLayout also does not read PYTHON_PATH, because some programs set this variable to their own libraries on installation. Hence "python-paths.txt".

I use both Windows and Linux environments for development. Setting up gds3xtrude on Linux is straight forward (setting aside a permissions issue). The instructions (above) when run on a Windows box will install the packages on the system, but the KLayout interpreter does not see the install location:

My solution was to switch back to Linux. This is now a heads-up to anyone trying to get gds3xtrude running on windows. It would be helpful if the install process was more self contained, but I understand the reasons why this isn't the case.

Unfortunately I don't have a Windows installation to reproduce the issue.

But I heard from other people who had difficulties because they had python3.7 installed but KLayout has python3.5 built-in. Therefore, when running pip3 the packages go to a directory explicitly for python3.7 and cannot be found by python3.5. The solution in this case is to install python3.5 if it is not already there and run pip3.5 instead of pip3.

3a8082e126