variables:
Z3_INSTALL_BIN_DIR - defaults to "bin"
Z3_INSTALL_LIB_DIR - defaults to "lib"
Z3_INSTALL_INCLUDE_DIR - defaults to "include"
This has two advantages
* We no longer hard code strings like "bin" all over the place
* Packagers can easily control where things get installed.
create_relative_symbolic_link(out, '/usr/lib64/libz3.so',
'/usr/lib/python3.5/site-package/libz3.so') would create an incorrect relative
path because it would consider ``/usr/lib`` to a be a path prefix of
``/usr/lib64``.
which would try to uninstall components that were never installed.
This bug would cause the following line to be emitted in the
``Makefile`` under the ``uninstall`` rule even though there was
no corresponding rule to install the file under the ``install`` rule.
```
@rm -f $(DESTDIR)$(PREFIX)/bin/test-z3$(EXE_EXT)
```
duplicated in too many places by refactoring the installation and
removal of the Python bindings to use the ``MakeRuleCmd`` class.
In order to make this change:
* ``PYTHON_PACKAGE_DIR`` no longer contains the text ``$(PREFIX)``
* ``PYTHON_PACKAGE_DIR`` **MUST BE** inside the installation prefix
duplicated in too many places and being worried that someone might
forget to use it when installing additional components.
To acheive this the new ``MakeRuleCmd`` class provides
several class methods to generate commonly needed commands used in
make file rules.
Most of the build system has been changed to use these helper methods
apart from stuff related to the Python bindings. This can't be changed
until we fix how PYTHON_PACKAGE_DIR is handled. Right it not guaranteed
to live under the install prefix but this is a requirement when using
the ``MakeRuleCmd`` methods.
There were several problems with the existing implementation.
* When specifying ``--prefix`` the implementation would assume the
path was ``$(PREFIX)/lib/python-<VERSION>/dist-packages``. This
is incorrect. ``dist-packages`` is Debian (and its derivatives,
i.e Ubuntu) specific and won't work on other Linux distributions
such as Arch Linux.
* When generating the ``Makefile``, ``$(PREFIX)`` was only emitted
during the Python installation when ``--prefix`` was passed on
the command line. When ``--prefix`` was not passed the absolute
path to the Python package directory was emitted. This is not
very consistent.
This patch checks that the detected Python package directory lives
under the install prefix and emits an error if it does not as this
indicates that the installation will be broken. If the Python package
directory does live under the install prefix it replaces that prefix
with the ``$(PREFIX)`` variable when emitting the ``Makefile`` for
consistency with the other install commands.
If a user really wants to install to a particular Python package
directory they can force it with the newly added ``--pypkgdir=``
flag.
when installing the Python bindings.
If ``DESTDIR`` is set the bindings will now be installed under this
path but ``$(PREFIX)`` only appears in the ``Makefile`` if ``--prefix``
was set which seems a little broken (we'll fix this soon).
The creation of the Python ``site-packages`` (and ``__pycache__`` for Python
3) directories has been moved to build time instead of configure time
because we don't know what ``DESTDIR`` will be set to at configure time.
DESTDIR make file variable (https://www.gnu.org/prep/standards/html_node/DESTDIR.html)
for ``install`` and ``uninstall`` targets.
Typically packagers build packages like so
```
$ ./configure --prefix=/usr/
$ make
$ make DESTDIR=/some/path/ install
```
Doing this installs the files into a directory ``/some/path`` but places
files inside that directory using the layout in ``--prefix`` (e.g.
``/some/path/usr/bin/z3``). The ``/some/path`` directory can then be
packaged (e.g. tarballed) for later installation.
The ``DESTDIR`` is not set in the Makefile and thus is empty by default
which maintains the existing ``make install`` behaviour.
Unfortunately this situation isn't fixed for the Python bindings (and
possibly others) yet as more invasive changes are needed here. I'll fix
this in later commits.
The previous version was racy and could lead to crashes.
The timer could be deleted before the callback was called, making it execute on already freed memory
This new version is similar to Mac's. It spawns its own thread and uses pthread_cond_wait.
Care is taken for small timeouts to avoid races in the thread creation and timer destruction.
Signed-off-by: Nuno Lopes <nlopes@microsoft.com>
