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
implement a Makefile target to measure code coverage of the testsuite #7049
Comments
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Still relevant! @Octachron and @shindere worked on this last summer with an intern (Lereena), but it would require yet more work before something can be upstreamed, because it is tricky to have a maintainable approach -- it's easy to hack the build system to assume (ppx_)bisect is available and do something useful, but it is hard to have a robust solution that allows self-contained builds and also coverage measurement. |
You could also use |
The explanations by @gasche are very accurate.
We considered using ocamlcp and ocamloptp and decided not to, but at the
moment I can't remember why. Can you, @Octachron ?
|
It was a choice between maintaining a back-end for generating good coverage reports from ocaml{c,opt}p or maintaining patchs to ppx_bisect front-end. |
Florian Angeletti (2020/10/19 08:52 -0700):
It was a choice between maintaining a back-end for generating good
coverage reports from ocaml{c,opt}p or maintaining patchs to
ppx_bisect front-end.
Ah right, thanks, @Octachron.
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
This is still an issue and I assigned it to myself.
It won't be fixed son because it has a lot of prerequisites on the build
system, e.g. being able to control where the compilation artifacts are
written.
Also, I think the title of the issue is a bit misleading. We indeed need
a way to measure how well the testsuite covers the compiler's code, but
the idea that this should be done through a dedicated make target is way
less clear to me. I'd rather say it's something that needs to be done by
configuring the testsuite correctly. It could even become a default or
something ocnfigure auto-detects and accomodates the build system to.
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Yes, still an issue.
|
Original bug ID: 7049
Reporter: @gasche
Assigned to: @chambart
Status: assigned (set by @gasche on 2015-11-19T16:25:40Z)
Resolution: open
Priority: low
Severity: feature
Target version: later
Category: configure and build/install
Bug description
Pierre proposes to implement a new Makefile target to compute code coverage inside the compiler internals (based on xclerc's bisect, if I understand correctly).
The text was updated successfully, but these errors were encountered: