* Introduce X-macro-based trace tag definition
- Created trace_tags.def to centralize TRACE tag definitions
- Each tag includes a symbolic name and description
- Set up enum class TraceTag for type-safe usage in TRACE macros
* Add script to generate Markdown documentation from trace_tags.def
- Python script parses trace_tags.def and outputs trace_tags.md
* Refactor TRACE_NEW to prepend TraceTag and pass enum to is_trace_enabled
* trace: improve trace tag handling system with hierarchical tagging
- Introduce hierarchical tag-class structure: enabling a tag class activates all child tags
- Unify TRACE, STRACE, SCTRACE, and CTRACE under enum TraceTag
- Implement initial version of trace_tag.def using X(tag, tag_class, description)
(class names and descriptions to be refined in a future update)
* trace: replace all string-based TRACE tags with enum TraceTag
- Migrated all TRACE, STRACE, SCTRACE, and CTRACE macros to use enum TraceTag values instead of raw string literals
* trace : add cstring header
* trace : Add Markdown documentation generation from trace_tags.def via mk_api_doc.py
* trace : rename macro parameter 'class' to 'tag_class' and remove Unicode comment in trace_tags.h.
* trace : Add TODO comment for future implementation of tag_class activation
* trace : Disable code related to tag_class until implementation is ready (#7663).
`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.
