and the cmake directory into a new directory ``contrib/cmake`` that
mirrors the directory structure of the root. This is a comprimise
between me and Christoph Wintersteiger that was suggested by Arie
Gurfinkel that allows the CMake build system to live in the Z3
repository but not impact the Z3 developers that want to avoid the CMake
build system. The build system will not work in its new location
and a bootstrap script will soon be provided that allows a developer
to copy the files back to their correct location.
``python_install_dir``. The implementation was broken because
we would strip off ``/usr`` and then install into
``/lib/python-3.5/site-packages``. We could remove the leading slash
to make sure we install into the CMAKE_INSTALL_PREFIX but doing so
seems unnecessarily complicated given that DESTDIR still seems to
be respected even when given absolute paths to the CMake ``install()``.
The new ``BUILD_PYTHON_BINDINGS`` option (off by default) will enable
building the bindings and the new ``INSTALL_PYTHON_BINDINGS`` option
enables installing them.
function ``mk_z3consts_py_internal()`` which called by a new
``mk_consts_files.py`` script. This will script will allow the const
declarations for the different Z3 language bindings to be generated.
Right now only support for python is implemented but more can be added
in the future.
``api_log_macros.cpp`` and ``api_commands.cpp`` optional in
``update_api.py``. This is required to implement support for
building and installing Z3's API bindings with CMake.
file ``api_dll.def`` and append the necessary flag to the linker
when using MSVC. The MSVC build with CMake now succeeds and both
the ``c_example`` and ``cpp_example`` work :)
is declared out of ``src/api/CMakeLists.txt`` and into
``src/CMakeLists.txt``. We will need this list to generate the
``api_dll.def`` module definition file for MSVC. Whilst I'm here
also fix a stray use of ``USES_TERMINAL`` in ``add_custom_command()``.
function ``mk_def_file_internal()`` which is called by a
new ``mk_def_file.py`` script. This will allow other build systems to
generate the ``api_dll.def`` file.
the stacksize flag used in the Python building system.
This was an effort to try and stop the Visual Studio build from emitting
the error message
```
70>LINK : fatal error LNK1104: cannot open file
'C:\Users\dan\dev\z3-1\build_console\Debug\z3.ilk'
```
Unfortunately this has not fixed the issue.
because this is passed to ``target_link_libraries()``. It just so
happens that ``target_link_libraries()`` will interpret arguments
starting with a dash as a flag to pass to the linker (i.e. in this
case ``-fopenmp``). However in the case of MSVC that flag is ``/openmp``
which is the interpreted as a file path which will lead to a linker
failure later because the linker can't find the file ``\openmp.obj``.
This is a large rework of my first attempt at this (#459).
This implementation calls into the recently implemented python scripts
to generate the necessary generated ``.h`` and ``.cpp`` files but is
independent from Python building system otherwise. Unlike the Python
build system, the generated files are emitted into the build tree to
avoid polluting the source tree. The build system is setup to refuse to
configure if it detects generated files in the source tree. If your
source tree is dirty you can run ``git clean -fx`` to clean your working
directory.
Currently the build succeeds on Linux using CMake 3.4.3 using
the "Unix Makefiles" generator with gcc or clang.
The following notable features are implemented:
* Building of the C and C++ examples and the ``test-z3`` executable.
These are included from the ``all`` target so you have to tell the
build system (e.g. make) to build them manually.
* Install (``make install``) and uninstall (``make uninstall``) of libz3
and its header files. This supports ``DESTDIR`` out of the box because
CMake supports it.
* An option (``BUILD_LIBZ3_SHARED``) to build libz3 as a static or dynamic library.
* Support for using/not using OpenMP (``USE_OPENMP``)
* Support for using/not using libgmp (``USE_LIB_GMP``)
* Setting the SOVERSION for libz3. I'm not sure if I'm setting the
* number correctly though. This is required by Linux distrubtions that
wills ship libz3. This needs discussion.
The following notable features are currently not implemented
and are left for future work.
* Support for ARM.
* Support for the foci2 library.
* Support for creating/installing/uninstalling the dotnet, java, python and ml
bindings.
* Full support for MSVC. Although I've tried to write the CMake code
with MSVC in mind not all the correct flags are passed to it.
* Support for using the git hash.
This new build system has several advantages other the old build system.
* It is easier for outside contributors to contribute to Z3 when the
build system is something more standard.
* Incremental builds work properly. With the old build system when
new code is pulled down the old build directory would need to thrown
out and a new fresh build had to be performed because the build system
didn't know how to correctly rebuild the project (e.g. couldn't handle
new sources being added/removed, compiler flags changing, generated
files changing, etc...). This is a MASSIVE boost to productivity!
* We now have access rich array of features that CMake provides for
building C/C++ projects. This means less time spent implementing
custom build system logic in Python that is already supported by
CMake.
* CMake supports many IDEs out of the box so it should be fairly
straight forward to build Z3 with Visual Studio (once support for MSVC
is added), Xcode, Eclipse CDT, CLion, ..etc.
be used as a script for other build systems and is callable via
a new ``generate_files()`` function from ``mk_util.py``. This removes
the horrible ``_execfile()`` hack that was previously in ``mk_util.py``.
Unfortunately lots of bad code is still in ``update_api.py`` but
fixing all of its problems is too much work right now.
function ``mk_gparams_register_modules_internal()`` which is called by a
new ``mk_gparams_register_modules_cpp.py`` script. This will allow other build systems to
generate the ``gparams_register_modules.cpp`` files.
function ``mk_mem_initializer_cpp_internal()`` which is called by a
new ``mk_mem_initializer_cpp.py`` script. This will allow other build systems to
generate the ``mem_initializer.cpp`` files.
function ``mk_install_tactic_cpp_internal()`` which is called by a
new ``mk_install_tactic_cpp.py`` script. This will allow other build systems to
generate the ``install_tactic.cpp`` files.
