Without /RELEASE passed to MSVC linker, the checksum field in exe/dll is not calculated. When you load the exe/dll in windbg (e.g., windbg -z libz3.dll), a warning "Unable to verify checksum" will show. With /RELEASE passed to linker, the warning will be gone.
Instead of doing this at configure time, we look at the actual
compile time status. This also avoids hardcoding checks based on
what CPU architecture is present, which doesn't work when Z3 is
being built on non-x86_64 platforms.
The `clock_gettime()` function in glibc < 2.17 required linking against
librt. Until #1437 nobody had tried using the CMake build system with
a really old version of glibc (in this case 2.12).
The python build system always linked against librt but the CMake build
system never tried to link against it leading to link failures.
This patch teaches the CMake build system to detect if librt is required
when linking against `clock_gettime()` and adds `rt` as a link
dependency if necessary.
This change means if the user explicitly passes `-DUSE_OPENMP=ON` to
CMake during the first configure and the compiler does not support
OpenMP the configure will fail but if the user doesn't specify it the
build system will automatically enable/disable OpenMP support depending
on whether it is supported by the compiler.
This is an improvement on the previous behaviour because previously we
would just emit a warning if `-DUSE_OPENMP=ON` was passed and the
compiler didn't support OpenMP.
before 4cc2b292c0.
It's useful to be able to control the defaults and CMake's internal
logic for GCC/Clang is simple enough that doing this makes sense.
It would be nice to do the same for MSVC but CMake's internal
logic is more complicated so for now it's better that we just use
CMake's default.
compiler defines and flags when using MSVC.
There are lots of defines and flags that I'm unsure about so in
some cases I've changed the behaviour slightly (if I'm confident
the behaviour in the old build system is wrong) or not added the
flag/define at all but just left comments noting what the old build
system did and why I disagree with the old build system's choices.
This analogous to the `--optimize` flag in the Python/Makefile
build system except that we now support doing LTO with Clang/GCC
as well. However it is probably best to avoid doing LTO with
Clang or GCC for now because I see a bunch of warnings about
ODR violations when building with LTO.
LTO can be enabled with the new `LINK_TIME_OPTIMIZATION` option
which is off by default.
using MSVC. This is set by the old build system but we weren't setting
it. This actually MSVC's default but in an effort to try to behave
more like the old build system we will set it anyway.
CMAKE_CXX_FLAGS_<CONFIG>, CMAKE_<TYPE>_LINKER_FLAGS, and
CMAKE_<TYPE>_LINKER_FLAGS_<CONFIG>.
This is useful for debugging where some flags come from. Now that
we don't explicitly set the defaults it useful to see which default
values we are getting from CMake.
The setting of overrides was broken (the CXX flags were not set but
the C flags were) and we aren't even using the C compiler any more.
The C compiler is used by the example C project but that is built
as an external project now so we don't need C support anymore.
The setting of defaults was also very fragile. CMake has quite
complicated support here (e.g. MSVC with a clang based tool chain) which
would likely not work properly with the override approach as it existed.
This means we loose some of the custom linker flags we were setting for
MSVC but we were never doing a great job of replicating the exact set of
flags used in the old build system anyway. Subsequent commits will
gradually fix this.
and install them. The target for building the documentation is
`api_docs`.
This is off by default but can be enabled with the
`BUILD_DOCUMENTATION` option. The C and C++ API documentation
is always built but the Python, ".NET", and Java documentation are
only built if they are enabled in the build system. The rationale
for this is that it would be confusing to install documentation
for API bindings that are not installed.
By default `ALWAYS_BUILD_DOCS` is on which will slow down builds
significantly but will ensure that when the `install` target is
invoked the documentation is up-to-date. Unfortunately I couldn't
find a better way to do this. `ALWAYS_BUILD_DOCS` can be disabled
to get faster builds and still have the `api_docs` target available.
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.
This patch detects a mingw64 build of the shared library and does not emit -fPIC to the compiler.
This is necessary to avoid a warning message, as Windows native code DLLs are generally relocatable
and not position independent.
When using Mono support for installing/uninstalling the bindings
is also implemented. For Windows install/uninstall is not implemented
because the python build system does not implement it and Microsoft's
documentation (https://msdn.microsoft.com/en-us/library/dkkx7f79.aspx)
says that the gacutil should only be used for development and not for
production.
For now a warning is just emitted if ``INSTALL_DOTNET_BINDINGS``
is enabled and the .NET toolchain is native Windows. Someone with
better knowledge of how to correctly install assemblies under Windows
should implement this or remove this message.
A notable difference from the Python build system is the
``/linkresource:`` flag is not passed to the C# compiler. This means
a user of the .NET bindings will have to copy the Z3 library (i.e.
``libz3.dll``) to their application directory manually. The reason
for this difference is that using this flag requires the working
directory to be the directory containing the Z3 library (i.e.
``libz3.dll``) but setting this up with multi-configuration generators
doesn't currently seem possible.
Previously tracing could be disabled and was not enabled by default in a
debug build. This isn't desirable but I had avoided fixing it because
enabling tracing in debug mode would be confusing because
``ENABLE_TRACING`` could be set to off but tracing would be enabled
anyway.
I have resolved this by renaming the option from ``ENABLE_TRACING`` to
``ENABLE_TRACING_FOR_NON_DEBUG``. The semantics of the optiona are now
that it will enable tracing in non-debug builds. I have also added code
to ensure that tracing is always enabled in debug builds.
Whilst I was here I also fixed how ``option()`` was being used. The
default value and comment were in the wrong order.
executables, include files and libraries. We use
``GNUInstallDirs.cmake`` which ships with CMake to do the difficult work
of setting a sensible default and setting up CMake cache variables.
These can be overriden when running CMake by setting the
``CMAKE_INSTALL_BINDIR``, ``CMAKE_INSTALL_INCLUDEDIR`` and
``CMAKE_INSTALL_LIBDIR`` cache variables.
to ``OFF`` to make it clear in ccmake/cmake-gui that the support is
disabled. Previously it would be left as ``ON`` even if support wasn't
actually enabled.
Most file generation scripts don't depend on it anymore.
The exceptions are uses of ``update_api.py``. An explicit dependency
has been added here and a ``FIXME`` has been left to indicate that this
should be removed once ``update_api.py`` is completly independent of
``mk_util.py``.
``mk_genfile_common.py`` and adapt ``mk_util.py`` and
``mk_consts_files.py`` to use the code at its new location. The
interface has been changed slightly so that
``mk_z3consts_py_internal()`` now returns the path to the generated
file. The motivation behind this is so that clients of the function
know the path to the generated file.
Whilst I'm here also reindent ``mk_consts_files.py`` and move some of
its code into ``mk_genfile_common.py`` so it can be shared.
Also update Z3_GENERATED_FILE_EXTRA_DEPENDENCIES in the CMake build
so it knows about ``mk_genfile_common.py``.
The purpose of this change is to have Python code common to the Python
and CMake build systems separate from Python code that is only used for
the Python build system.
a list ``Z3_GENERATED_FILE_EXTRA_DEPENDENCIES`` that is used by
the ``add_custom_command()`` declarations. This will let
us easily change the common dependencies for generating build files in
the future.
is applied to targets. The ``LINK_FLAGS`` property of a target is
a string and not a list and so if ``Z3_DEPENDENT_EXTRA_CXX_LINK_FLAGS``
contained more than one flag the linker line would end up being
``-flag1;flag2;flag3;...`` which would not work. Now we use a new
function ``z3_append_linker_flag_list_to_target()`` to iterate through
the list and update the ``LINK_FLAGS`` property of the specified target
correctly.
