-
Notifications
You must be signed in to change notification settings - Fork 13
Add tests for dune wrapped libraries #31
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
Conversation
d31467a to
07c98a6
Compare
This is in preparation of adding a `wrapped_lib` that will follow the same architecture and usage as `unwrapped_lib`. Having both mixed together in `bin/` would be too noisy. Hence, creating a `bin/use_unwrapped_lib` subdir will isolate their use. Later, a `bin/use_wrapped_lib` will do as well.
This is in anticipation of the upcoming `wrapped_lib` directory that would contain the same code as `wrapped_lib` with a different `dune`. To avoid a large copy of all the code, they would both contain symlinks to the `lib`'s subdirs (which actually contain the code).
It was referencing a value from `Values` instead of `Values_no_intf`. This value is not included in the results because it is used too often to be reported with the tested thresholds.
`wrapped_lib` is a copy `unwrapped_lib` with a change in the `dune` fields: `(wrapped true)` (instead of `false`). The `use_wrapped_lib` is also a copy of `use_unwrapped_lib` with an extra module indirection to access elements in each `.ml` file. The `.exp` files have been updated by copying the expected reports for the `unwrapped_lib` to define expected reports for the `wrapped_lib`. In the future, new examples should be added in a subdir of `lib`, symlinked in both `unwrapped_lib` and `wrapped_lib`. Consequently, the "copy" property of their reports should hold. The new `.ref` files show that dune's wrapping of module is not an issue for the tracking of optional arguments and stylistic issues. It is only an issue for the default reports.
|
If that's OK with LexiFi, in order to maintain the project's momentum, I'll merge non-critical PRs (tests, doc, ...) after 1 week if they don't get any review, and more involved ones (features, improvements, ...) after 10-14 days. Critical changes (breaking change, version update, ...) will still expect a review. |
|
Sounds good @fantazio. At this point you are the main driving force behind this project, and we appreciate that! Thanks! |
|
(Incidentally, we have some users inside LexiFi who are are looking forward to using the tool, once it works on 5.3.0 :)) |
|
I am aiming at OCaml 5.3 before 2026. |
A preview of the OCaml 5.3 compatibility is available here #38. There is still some work to do but feel free to play with it and comment or open issues (or sub-issues of #39). Feedback is always helpful. |
This is an initial work for #18, which clearly states the issue.
The new
wrapped_libshares the same code asunwrapped_libby having both symlink to the same source directories located inlib. The only relevant difference between the 2 is the(wrapped <boolean>)field in theirdunefiles.The
use_*files inbinare moved to thebin/use_unwrapped_libdirectory. The newbin/use_wrapped_libdirectory is a copy of the unwrapped version, with an extra module indirection (Wrapped_lib) to access elements in the lib's modules.The expected reports for
unwrapped_libandwrapped_liband theirbin/use_*_libcompanion are identical. In the future, new examples should be added in a subdir oflib, symlinked in bothunwrapped_libandwrapped_lib. Consequently, the "copy" property of their reports should hold. Similarly, an update inbin/use_*_libis expected to be replicated in the other, and the property would hold for their reports too.The updated
.reffiles show that dune's wrapping is not an issue for the tracking of optional arguments and stylistic issues. It is only an issue for the default reports.