file for the build and install tree.
These files allow users of CMake to use Z3 via a CMake config package.
Clients can do `find_package(Z3 CONFIG)` to get use the package from
their projects.
When generating the files for the install tree we try to generate
the files so that they are relocatable so that it shouldn't matter
if the installed files aren't in the CMAKE_INSTALL_PREFIX when
a user consumes them. As long as the relative locations of the files
aren't changed things should still work.
A new CMake cache variable `CMAKE_INSTALL_Z3_CMAKE_PACKAGE_DIR` has been
added so that the install location of the Z3 CMake package files can be
controlled.
This addresses #915 .
CMake will automatically pick up changes in git's HEAD so that
the necessary code is rebuilt when the build system is invoked.
Two new options `INCLUDE_GIT_HASH` and `INCLUDE_GIT_DESCRIBE` have been
added that enable/disable including the git hash and the output of `git
describe` respectively. By default if the source tree is a git
repository both options are on, otherwise they are false by default.
To support the `Z3GITHASH` macro a different implementation is used from
the old build system. In that build system the define is passed on the
command line. This would not work well for CMake because CMake
conservatively (and correctly) rebuilds *everything* if the flags given
to the compiler change. This would result in the entire project being
rebuilt everytime git's `HEAD` changed. Instead in this implementation
a CMake specific version of `version.h.in` (named `version.h.cmake.in`)
is added that uses the `#cmakedefine` feature of CMake's
`configure_file()` command to define `Z3GITHASH` if it is available and
not define it otherwise. This way only object files that depend on
`version.h` get re-built rather than the whole project.
It is unfortunate that the build systems now have different `version.h`
file templates. However they are very simple and I don't want to
modify how templates are handled in the python/Makefile build system.
`INTERFACE` was the not appropriate usage requirement to use. However
it only caused a problem when USE_LIB_GMP was enabled. With `INTERFACE`
`-lgmp` was not specified on the link line so `libz3.so` did not have a
reference to the library and linking against `libz3.so` by clients
would fail with missing references to symbols in `libgmp`.
We don't install Z3_DOTNET_ASSEMBLY_DLL into the gac. Instead we just copy into
installation directory.
There are several reasons for this:
* We can't install the Z3_DOTNET_ASSEMBLY_DLL into the gac in a portable
way like we can with mono (i.e. the ``-root`` flag).
* It isn't best practice to use ``gacutil.exe``
on Windows to install into the GAC, see
https://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).aspx .
Taking this approach should be sufficient because we can now do
something like this
```
mkdir build
cmake -G Ninja -DCMAKE_INSTALL_PREFIX=<some_path> ../
ninja
mkdir <some_path>
ninja install
```
and then put the contents of <some_path> into a zip file which creates a redistributable zip file for Windows.
and ``Microsoft.Z3.xml`` to the root build directory rather than
``<root_build_directory>/src/api/dotnet``.
This fixes#573 which makes the behaviour consistent with the Python
build system.
using CMake 2.8.12.2. It seems ``install_jar()`` in the version of
``UseJava.cmake`` shipped with that version of CMake doesn't handle
the ``DESTINATION`` argument correctly and treats that as the
installation location so CMake would install to
``/usr/local/DESTINATION`` rather than ``/usr/locale/share``.
the ``.jar`` file is created as ``com.microsoft.z3-4.4.2.0.jar``
and a symlink named ``com.microsoft.z3.jar`` is created which points
to it in the build and install directory.
I'm not entirely happy with some parts of the implementation
* The default locations for installing ``com.microsoft.z3.jar`` and ``libz3java.so``
aren't correct. CMake cache variables have been provided that allow the user to change
where these get installed.
* The name of ``libz3java.so``. It doesn't conform to the Debian
packaging guidelines (https://www.debian.org/doc/packaging-manuals/java-policy/x126.html)
and I have not provided an option to change this.
* The fact that ``SONAME`` and ``VERSION`` are not set on ``libz3java.so``.
These issues should be addressed once we know the correct way to handle
installation.
