for the ".NET" bindings example.
Previously there was a hack that would to path separator replacement
( '/' -> '\' ) which breaks paths under non-windows platforms. The hack
has been made slightly better by doing ( '/' -> os.path.sep). This
preserves the existing behaviour under Windows and unbreaks the build
on non-windows platforms.
I'm not entirely sure why the path replacement needs to be done in
the first place. I thought Windows was supposed to support using
'/' as a path separator (as well as '/'). Maybe ``csc.exe`` doesn't
support these kind of paths?
the install prefix on OSX less aggressive by not stating that this might
lead to a broken install (even though it might!).
Also emit a similar warning during the configuration step.
This partially addresses #361
the install prefix on OSX less aggressive by not stating that this might
lead to a broken install (even though it might!).
Also emit a similar warning during the configuration step.
This partially addresses #361
under OSX when the Python ``site-packages`` directory doesn't live
under the install prefix. Also disallow installing under Windows
as it doesn't really make sense.
was not created before trying to create files in it.
The ``install_deps()`` method was also dead. It looks like that
should have been named ``mk_install_deps()`` but even if we give it
the right name it does the wrong thing. That method is supposed
emit target names (i.e. dependencies) not commands.
".NET" bindings. This file is required for Monodevelop to find the
bindings because Monodevelop uses pkg-config to find packages
(it doesn't use the GAC).
For lack of a better name the GAC (and pkg-config) package name is now
``Microsoft.Z3.Sharp``. I don't want to call it ``Microsoft.Z3`` because
someone may want to create a ``Microsoft.Z3.pc`` file in the future for
the native Z3 library (i.e. C++ or C bindings).
In addition there is a new utility function ``configure_file()``
which reads a template file, applies some substitutions and writes
the result to another file. This very similar to what CMake does.
There is a new environment variable ``Z3_INSTALL_PKGCONFIG_DIR``
which allows pkgconfig directory to be controlled for the install.
under non Windows systems (i.e. Using mono).
Building these bindings is unfortunately on by default because
I didn't want to change the command line interface (i.e. ``--nodotnet``)
which people might be relying on. This should really be changed to
match the other binding flags (e.g. ``--java``) but I will leave
this for now.
To perform the build a C# compiler and the GAC utility are required.
The script will try to automatically detect them but the user can
override this by setting the ``CSC`` and ``GACUTIL`` environment
variables.
In order for the ".NET bindings" to be installed the assembly
(``Microsoft.Z3.dll``) needs to have a strong name which means
we need a Strong name key file which is what the
``Microsoft.Z3.mono.snk`` is for. This is the public and private
key so this key **must never** be used for checking integrity. Instead its
only purpose is to avoid any name clashes in the GAC.
It is also worth noting that slightly different flags needs to
be passed to the C# compiler on non Windows platforms. I don't
understand why some of the flags are being used on Windows but I left
a comment there that hopefully someone can fix...
variables:
Z3_INSTALL_BIN_DIR - defaults to "bin"
Z3_INSTALL_LIB_DIR - defaults to "lib"
Z3_INSTALL_INCLUDE_DIR - defaults to "include"
This has two advantages
* We no longer hard code strings like "bin" all over the place
* Packagers can easily control where things get installed.
create_relative_symbolic_link(out, '/usr/lib64/libz3.so',
'/usr/lib/python3.5/site-package/libz3.so') would create an incorrect relative
path because it would consider ``/usr/lib`` to a be a path prefix of
``/usr/lib64``.
