Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Install solvers to a relevant site-package by default #517
Heads up -- all installs pass on all platforms, and all unittests succeed (check here).
The only thing currently failing are additional examples run in "all solvers" case. PySMT import fails there for some reason. Working on it (but it's so painfully slow to debug this on Travis - in the best case you need to wait for 30m+ to compile/install all solvers, just to run the actual test after that. Sometimes tests segfault, and sometimes archive download timeouts).
All righty, all good now. The problem was with
Since we don't need to extend
Btw, tests are now modified to (by default) install all solvers according to the default bindings dir heuristic in the installer. I.e. we're also testing that works.
If you want to run tests with custom/explicit bindings dir, set
referenced this pull request
Aug 14, 2018
Looks good. Only some minor changes, I can do those.
Regarding the CI, we need to fix the caching mechanism.
What directory do we need to cache now? I guess ~/.local/bin on linux ? What about macOS?
For the same reason, I re-triggered the CI on travis after deleting the cache.
Since the current Travis build uses virtual env, python bindings for solvers are installed in site-packages inside that env. So maybe you can cache the complete virtual env for the project?
The path to the virtual env root is (for python 3.6 build):
If you want me to patch something, just let me know. From the comments above, I'm not exactly sure what would you like to be changed... Goes without saying, please feel free to modify/amend my PR to your liking.
This is a known issue that we have been trying to isolate for a while. Nothing to do with yhis particular pr. It is difficult to debug because I managed to reproduce it only once on my machine and otherwise it is non deterministic. One idea of the cause is the an incorrect use of the refcount mechanism in our z3 converter. I was reviewing it a few weeks ago, but did not find anything suspicious. We might try to upgrade z3, if there is a more recent version available.