The issue is with "dllexport": previously, dllexport was present on
exposed templates tool (= visibility(default) for gcc/clang). This
ensured MacOS compatibility since then the typeinfo is corretly
shared and dynamic_cast/typeid works.
For Windows, the "dllexport" equivalent requires the template
instantiations to be declared "external" which is a coding nightmare.
The solution is to provide separate macros for real (non-specialized,
not explicitly instantiated) templates (.._PUBLIC_TEMPLATE) which
is defined as empty for Windows and "visiblity(default)" for gcc/clang.
1.) Startup issue:
This is solved by making sure templates with virtual functions
are made visible in the DSO. This way, dynamic_cast is possible
across DSO's.
Scary: clang/MacOS wants the forward declarations be declared visible as well.
2.) Menu issue:
The best solution is to have only one QMenuBar. The navigator
now gets a synthetic menu bar composed of QToolButtons.
* Moved tlSystemPaths into lay namespace where it belongs
* Doc updates
* New command line switch -y and -yd for unattended installation
* Download URL's can be relative to salt.mine URL
* KLAYOUT_HOME environment variable to make ~/.klayout configurable
* Better error messages on XML parser on file/stream read errors
(specifically from http/https)
The goal of the refactoring is to support unit tests
for the db library.
For this, a distributed unit test concept has been
introduced (later to be extended to other libs).
Unit tests are shared objects called ".ut" and are
automatically loaded by the ut runner. The bd library
now has two folders - one for sources and one for the
unit tests. The sources are separated into lib and apps.
First unit tests for the writer options have been
provided.
* To reduce the redundancy
* To enable testing of the bd library including the apps
The apps are entirely configured through their names.
Their .pro files are identical and the app implementation
is inside the bd lib (partially generic too). Hence the
apps can be tested by bd library unit tests.
* Generic writer options
* Generic reader options
* All converter tools are equipped with writer options
* strm2gds is equipped with reader options already
This commit deals with the deployment issue on Windows
where there is no global Ruby/Python installation and
the installer needs to package all required files.
The solution is to read the Ruby/Python path from a
file that is evaluated upon startup. The installer will
install these files together with the executable for
Windows. This feature is only enabled on Windows.
A specific issue occured: since the location of the
file needs to be determined, the path of the executable
needs to be known. The Ruby initialization requires the
path to be set very early, before QCoreApplication is
instantiated. But Qt complains in QCoreApplication::applicationDirPath
so that this approach cannot be used for this purpose.
Bug: sometimes, if the files had different database units, the XOR
tool was showing differences while there are none.
This was due to a sloppy computation of the tile boxes. The solution
is to properly round the tile size to a common database unit and
to use a common effective size for both inputs.
- Massive performance improvement with debugger - trace was
eventually clearing the file to id map.
- UI updates on debugger did not happen because delayed
execution of functions got disabled.
Matthias Koefferlein
matthias
Pankaj Pandey