klayout icon indicating copy to clipboard operation
klayout copied to clipboard

KLayout is now available in hdl/containers

Open umarcor opened this issue 3 years ago • 2 comments

@Fatsie added KLayout to hdl.github.io/containers (hdl/containers#21), so it's ready to use for Docker/Podman users on Linux, Windows and/or MacOS (amd64 hosts only, for now). See the following screencast using x11docker, runx and VcxSrv on Windows 10 (MSYS2/MINGW64):

While doing so, some questions arised, which I hope to get answered in this issue:

  • Executing klayout -v or klayout -h fails if no X server is available. Option -b is required. However, AFAAIU those commands are to be used in CLI only. Hence, I'd like to suggest allowing them to be executed without batch mode.

  • According to the documentation, it should be possible to build KLayout with clang, instead of GCC. Unfortunately, I did not succeed in doing so. The build environment is a Debian Buster container with clang, CC=clang and CXX=clang++. I tried passing QEMU_CC and QEMU_CXX, both by exporting them and by passing them through -option, but none of them succeeded. This is the build procedure: https://github.com/hdl/containers/blob/main/debian-buster/klayout.dockerfile#L37-L49. And this is one of the failing tests with clang: https://github.com/hdl/containers/runs/2162854151?check_suite_focus=true#step:4:1447

  • We normally use PREFIX=/usr/local and DESTDIR=/opt/klayout. For KLayout, we set -bin /opt/klayout/usr/local/bin and -rpath /usr/local/lib. On the one hand, I'm not completely sure about it matching our expectations. On the other hand, it seems that some resources are not copied automatically. We had to mv libklayout* db_plugins lay_plugins ../lib/. Is this expected or is it a misusage on our side?

umarcor avatar Mar 23 '21 04:03 umarcor

@umarcor Thanks for this wrap-up

I guess it's possible to imply -b when using -v or -h. So far no one requested this.

I'm building with clang on Linux myself. Also MacOS is based on clang, so I don't think there is a general issue with clang. In this log I see a message about missing g++: "sh: 1: g++: not found". To force qmake to use clang, I use "build.sh -qmake 'qmake -spec linux-clang' ...".

I have some doubts about the lib/bin separation. In general, I'd not advise to use separate directories for lib and bin. Technically there is a single INSTALLDIR only and that is the bin directory in your case. So eventually this is where the files get installed to. I'd also opt for using "-bin /usr/local/lib" (which should imply the -rpath) and move the klayout executables (klayout and strm*) to bin. Maybe that's finally easier. I guess it's possible to extend build.sh to support separate destination folders for lib and bin.

Thanks,

Matthias

klayoutmatthias avatar Mar 29 '21 21:03 klayoutmatthias

Hi Matthias! Nice to meet you!

I guess it's possible to imply -b when using -v or -h. So far no one requested this.

I understand it's an uncommon use case. KLayout is mostly to be used graphically, so it's weird for someone to try using it without an X server being available. Since we can work around it with -b (https://github.com/hdl/smoke-tests/blob/main/klayout.sh#L13-L17), this is not critical.

I'm building with clang on Linux myself. Also MacOS is based on clang, so I don't think there is a general issue with clang. In this log I see a message about missing g++: "sh: 1: g++: not found". To force qmake to use clang, I use "build.sh -qmake 'qmake -spec linux-clang' ...".

Thank you so much. That -qmake 'qmake -spec linux-clang' is what I needed! https://github.com/hdl/containers/commit/099f7c4d77569f35ae32e129e7bd50479765d7b0 I guess it might be obvious for qmake users, but I couldn't find a reference to -spec linux-clang in https://www.klayout.de/build.html, so I was quite lost 😊

I have some doubts about the lib/bin separation. In general, I'd not advise to use separate directories for lib and bin. Technically there is a single INSTALLDIR only and that is the bin directory in your case. So eventually this is where the files get installed to. I'd also opt for using "-bin /usr/local/lib" (which should imply the -rpath) and move the klayout executables (klayout and strm*) to bin. Maybe that's finally easier. I guess it's possible to extend build.sh to support separate destination folders for lib and bin.

The point here is that we are building KLayout on one environment and generating a "tarball". Then, on a different environment, we install runtime dependencies and we extract the tarball. Hence /usr/local is the location of the final installation, and that's where libraries, etc. should be looked for. However, we don't want build.sh to copy the assets to that location, because we don't want to cherry-pick them mixed in the build environment.

Hence, we don't want to use separate bin and rpath directories per se. Ideally, both of them would be /usr/local and there would be another option (INSTALLDIR or DESTDIR) which is used for copying the assets only. See a typical makefile based procedure: https://github.com/hdl/containers/blob/main/debian-buster/z3.dockerfile#L40-L41.

Cheers

Unai

umarcor avatar Mar 30 '21 03:03 umarcor