Previously CMake was not aware of which headers files the generation
of `gparams_register_modules.cpp` depended on. Consequently this could result
in broken incremental builds if
* Existing headers that declared module description/parameters change.
* New headers are added that declare module description/parameters.
* `.pyg` files that generate header files that declare module
description/parameters change
Now the `z3_add_component()` CMake function has been modifed so that
* All header files that are generated from `.pyg` files are added as
dependencies and are scanned from module description/parameter
declarations. This implicit dependency of `gparams_register_modules.cpp`
depending on other generated header files seems unnecessary complex. We
should revisit this design decision once the Python/Makefile build
system is deprecated.
* The function now takes an optional `EXTRA_REGISTER_MODULE_HEADERS`
argument which allows the headers that declare module
description/paramters to be explicitly listed.
With this information CMake will now regenerate `gparams_register_modules.cpp`
correctly.
This required the `mk_gparams_register_modules_internal()` function to be
changed to take a list of header files rather than a list of component
source directories. The two consumers (CMake and Python/Makefile build
systems) of this function have been modified to work with this change.
This partially fixes#1030.
Previously CMake was not aware of which headers files the generation
of `install_tactic.cpp` depended on. Consequently this could result
in broken incremental builds if
* Existing headers that declared tactics/probes changed.
* New tactics/probes were added to new header files.
Now the `z3_add_component()` CMake function has been modifed to take an
optional `TACTIC_HEADERS` argument which allows the headers that declare
tactics/probes to be explicitly listed. The necessary component
declarations have been modified to declare their tactic/probe header
files.
With this information CMake will now regenerate `install_tactic.cpp`
correctly.
This required the `mk_install_tactic_cpp_internal()` function to be
changed to take a list of header files rather than a list of component
source directories. The two consumers (CMake and Python/Makefile build
systems) of this function have been modified to work with this change.
This partially fixes#1030.
`contrib/cmake/bootstrap.py` script no longer needs to be executed.
The previous location of the CMake files was a compromise proposed
by @agurfinkel in #461. While this has served us well (allowing progress
to be made) over time limitations of this approach have appeared.
The main problem is that doing many git operations (e.g. pull, rebase)
means the CMake files don't get updated unless the user remembers to
run the script. This can lead to broken and confusing build system
behaviour.
This commit only does the file moving and necessary changes to
`.gitignore`. Other changes will be done in subsequent commits.
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.
