Fix coverage for recent lcov (>= 2)#234
Fix coverage for recent lcov (>= 2)#234ddeclerck wants to merge 1 commit intoOCamlPro:gcos4gnucobol-3.xfrom
Conversation
|
The macro was updated in 2024 and explicit does not have the tmp part in any more https://gitweb.git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_code_coverage.m4, let me update that (and possible other m4 macros - that's planned in any case) and see where it leads. |
|
The big question not answered here yet: does your configuration work with lcov 1 (at least 1.16, which is in Debian stable) as well? |
|
Answer to my question: just using |
|
For the errors - we could use --exclude with the ignore pattern automatically in the macro, while this can be done with lcov 1 as well (which does not error in the case that source files from gcdata are not found) - but sadly that doesn't skip the file open - see linux-test-project/lcov#411 This effectively leaves only the warning about deprecated options in, which we can live with (until the option is removed, so hopefully the autoconf-archive m4 is adjusted and updated until then). |
Yeah, I noticed that. Note that Also note that all the proposed fixes are only in the workflow definition, which is unlikely to rollback to an older version of lcov. |
Yes, but the issue is that users run it as well, and we don't want coverage to error then :-) |
|
Part of this is handled upstream; running code-coverage in a subtree (where the srcdir has the generated bison/flex files directly in cobc) raises warnings about the generated files not being in the subtree (ignored) and same for scanner.l (abort) ?!? |
Yes, I mentionned that in my initial comment, that's why we need Anyways, I rebased and checked the results, both with lcov 1.15 and lcov 2. |
|
That's nice. The remaining question is if we can make those two conditional in the code-coverage m4 macro depending on the lcov version - because otherwise this will be broken outside of the CI (either for lcov1 or lcov2 environments). |
Are you suggesting we modify To me it would be okay to not use those new options for now and let the deprecation warning occur... |
Yes, then send it upstream for review and maintenance.
Me neither, but that m4 file is mostly shell-script written in macro-style.
If everything works without those options and we just get warnings, then that would be fine for now - does it work with ubuntu-latest and without those options? |
|
Friendly ping @ddeclerck |
This PR attemps to fix coverage with recent versions of lcov.
This is achieved through different options, each solving a different problem.
This is required because this appears in the logs:
Note that the
/tmp/*pattern is added bym4/ax_code_coverage.m4, so maybe an updated version of this M4 script would work with newer versions of lcov ?This is required because this appears in the logs:
This error occurs for all generated files (
cobc/pplex.c,cobc/scanner.c,cobc/ppparse.c,cobc/parser.c), probably because they are in the source tarball and hence missing from the build directory (copying them here would also workaround the error). Since all these files are inCODE_COVERAGE_IGNORE_PATTERN, it seems safe to ignore this error anyways, as we're doing here.Then, we also apply a "fixup" for a warning:
Needed because we have this:
Finally, to be more future-proof, we define those:
Because we have these warnings:
But maybe an updated version of
ax_code_coverage.m4could work ?