- Using "Library" rather than "Extension" for building shared libs
(does not try to export extension-specific symbols)
- Linking against import libs
- Using os.path.join consistently for backslash/slash difference
Cause: dbInit.cc:133 hardcodes the macos extension for shared libraries ('.dylib'), but setuptools builds it with '.so'.
Current solution: Since the main build's qmake respects the dylib standard, I've adapted setuptools to use '.dylib'.
With these fixes, unit tests pass with MacOS
(set DYLD_LIBRARY_PATH!)
1.) MacOS takes popen vs. pclose seriously
By using fopen we basically spoil the system and other popen
won't work.
2.) For system integrity, MacOS does not propagate DYLD_LIBRARY_PATH
to child processes such as sh. This has to be done explictly.
3.) Search the klayout binary in the right path (klayout.app/...)
4.) Reset KLAYOUT_HOME for less intervention by installed macros
The comments for LoadLayoutOptions#layer_map, #cif_layer_map
and #dxf_layer_map have been updated to reflect the new status
of these properties (which have been methods). The tests
are updated accordingly (layer_map() -> layer_map).
The issue was: for MacOS/clang, the virtual format-specific
option structs had to be embedded in one compile unit (for RTTI).
In Windows this will lead to link errors since the DLL is not
reachable at build time for the generic reader/writer configuration in
the buddy tools.
The solution is to use GSI methods (provided for scripting) to
set the reader/writer options in a generic way that does not
require linking against the plugin DLLs.
I am going to test uploading klayout as module to pypi, but it requires unique naming. Therefore, there can only be one klayout-0.26.0 version. Only stable versions ("releases") should ever be uploaded. bugfix-patched versions should be named 0.26.0.post1 etc.
Unlike Linux, RTTI does not work in MacOS/clang when the classes
originate from different compile units. I think that Linux's C++
runtime not only checks for identical vtable, but alternatively
for same name. On MacOS, dynamic_cast will fail instead. This fix
solves this issue by placing the important steam format option
specializations into a single specific shared object (the DB plugin).
This fix assigns proper library IDs and load paths for the dependent
libraries even if they are distributed among several directories.
This is in particular important for the stream and tool plugins
which exist in a folder next to the application but have to refer
to libraries from the Frameworks folder.
The fix consists of extending the library analysis within build4mac.py
and supplying an additional directory listing the target directories.