-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add python bindings for configurations #125
base: vara-dev
Are you sure you want to change the base?
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## vara-dev #125 +/- ##
============================================
- Coverage 89.74% 89.73% -0.02%
============================================
Files 73 73
Lines 6991 7001 +10
============================================
+ Hits 6274 6282 +8
- Misses 717 719 +2
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except for the comment below, LGTM
if os.path.exists('/lib/x86_64-linux-gnu/libz3.so'): | ||
cmake_args.append('-DVARA_FEATURE_BUILD_Z3_SOLVER=False') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this is a good way to determine if we should build the solver.
- the path is a system specific
- we might want to build the solver from scratch even for those system, as we depend on a very specific version of z3. (The debian 11 can cause problems)
Maybe we should keep building the solver as the default and give the user a option to disable that? Or, if it works for you, only you use the local one.
For some reason, this caused other configs to appear multiple times during enumeration.
This caused 2 issues: - either first config was skipped or getCurrentConfig would always point to the next configuration - getAllValidConfigurations or getNumberValidConfigurations produce incorrect results if called after any call to getNextConfiguration() The last point is an issue with the Solver API and this is a quick-fix for the Z3Solver implementation that returns an error in that case.
This implementation is quite hacky and requires a redesign of the Solver API to be fixed properly.
auto FM = feature::loadFeatureModel( | ||
getTestResource("test_msmr.xml")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[clang-format] reported by reviewdog 🐶
auto FM = feature::loadFeatureModel( | |
getTestResource("test_msmr.xml")); | |
auto FM = feature::loadFeatureModel(getTestResource("test_msmr.xml")); |
No description provided.