build directory would cause REV_BUILD_DIR to be set incorrectly and
would lead to a broken Makefile being generated.
What would happen before:
```
$ python scripts/mk_make.py --build FOO_1
...
REV_BUILD_DIR='..'
```
```
$ python scripts/mk_make.py --build FOO_1/
...
REV_BUILD_DIR='../..'
```
^^^^^ that's wrong. It should be REV_BUILD_DIR='..'
To fix this the ``reverse_path()`` function has been taught to ignore empty
components in ``p.split(os.sep)``.
when using Python2.
The output from ``check_output()`` has ``unicode`` type under
Python 2 but type ``str`` under Python 3. This type ended up being
used inside the ``MakeRuleCmd`` class which asserts that it receives
paths of type ``str``. To fix the problem under Python 2 the asserts
have been made weaker by also allowing the paths to be of type
``unicode``.
variable. Previously it would try to install into the system (e.g.
``/usr/lib/ocaml``) regardless of the value of DESTDIR.
Unfortunately it looks like packagers who use DESTDIR to do staged
installs will need to have their packages patch their user's OCaml
``ld.conf`` file manually at package install time (not ``make install``
time) with the extra path to the Z3 Ocaml package directory. We could
use the ``touch`` command to create an empty ``ld.conf`` before running
``ocamlfind install`` but that adds the wrong path to ``ld.conf``
because it contains DESTDIR.
bindings is enabled. That is really unhelpful behaviour. Instead emit a
warning. I would prefer an error message but apparently being able to
build but not install the OCaml bindings is desirable.
Whilst I'm here also print information about ocamlfind where it should
have been mentioned.
Previous method is_osx_hack didn't exist, possibly wasn't cleaned up. This
change has been tested and Z3 compiles successfully within a 2.7 virtualenv
running on OS X 10.10.5.
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.
