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.
@nunolopes .
If `pthread_cond_signal()` is called while `m_mutex` is held then the
timing thread might be woken up twice due to waking up from
`pthread_cond_timeout()` (due to being signaled) but then being forced
to sleep again because the thread calling `~imp()` is still holding
`m_mutex` (which the timing thread needs to acquire).
incorrectly assumed that `pthread_cond_timedwait()` would exit
due to a condition variable being signaled or a timeout occuring.
According to the documentation `pthread_cond_timedwait()` might
spuriously wake so we introduce a new variable `m_signal_sent` (that is
guarded by an existing mutex) that is used as the variable to check that
the thread wake was not spurious.
This is intended to partially fix#839 .
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.
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.
