Code coverage report

[HugoMVale]

Hello,
Does fpm have a built-in way to trigger the generation of an xml code coverage report, i.e. something like fpm test --coverage?
If not (or not yet):

1. Is there an option (e.g., a compiler option) that we can add to fpm.toml file to achieve the desired result?
2. If the toml approach is not feasible, what would be the most straightforward way to generate a coverage report (assuming gfortran).

Thanks!

[HugoMVale]

Hello,
I guess I will try to answer my own question! ;)
As described in RAL-TR-2009-019, 3 steps are required to generate a coverage report (assuming gfortran):

1. Compile the source code with flag --coverage and without optimizations.
2. Run the tests, which will generate *.gcda files containing the coverage data.
3. Use gcov to process the *.gcda files and create corresponding *.gcov files with coverage metrics.

Using fpm, steps 1 and 2 can be performed with a single command line:

fpm test --profile debug --flag --coverage

This has the (undesirable) side effect of generating *.gcda files for everything (not just the source files of the package), but we can deal with that in the next step.
Step 3 can be done with:

gcov ./build/gfortran_*/package-name/src*.gcda -r ./src/ -b

The file pattern specifier src*.gcda is necessary to restrict the analysis to source code files (otherwise, test files, dependencies, etc. would be analyzed as well).
If someone has an alternative method, I would love to hear about it!

[arjenmarkus]

The general procedure you describe seems fine to me. The details differ per compiler though and I have noticed that the documentation is not always that fantastic ;). Op vr 9 sep. 2022 om 18:39 schreef HugoMVale ***@***.***>:

…

Hello, I guess I will try to answer my own question! ;) As described in RAL-TR-2009-019 <https://epubs.stfc.ac.uk/manifestation/4395/RAL_TR_2009_019.pdf>, 3 steps are required to generate a coverage report (assuming gfortran): 1. Compile the source code with flag --coverage and without optimizations. 2. Run the tests, which will generate *.gcda files containing the coverage data. 3. Use gcov to process the *.gcda files and create corresponding *.gcov files with coverage metrics. Using fpm, steps 1 and 2 can be performed with a single command line: fpm test --profile debug --flag --coverage This has the (undesirable) side effect of generating *.gcda files for everything (not just the source files of the package), but we can deal with that in the next step. Step 3 can be done with: gcov ./build/gfortran_*/package-name/src*.gcda -r ./src/ -b The file pattern specifier src*.gcda is necessary to restrict the analysis to source code files (otherwise, test files, dependencies, etc. would be analyzed as well). If someone has an alternative method, I would love to hear about it! — Reply to this email directly, view it on GitHub <#746 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR6YVVGGIUXMIF2GSM3V5NR2NANCNFSM6AAAAAAQGOC224> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[urbanjost]

I have a much more complicated but very target-specific version that allows me to just enter "fpm coverage" but you can use response files as described at the M_CLI2 module github site, or create a plugin script. Assuming you are on a platform with bash annamd that you
name the script "fpm-coverage" and put it in your command path you could then enter "fpm coverage". The main trick the script shows
is how to get the directory name, the rest would have to be fleshed out. I usually write the plug-in in a scripting language and then once
the basics are working, I rewrite it in Fortran. I have ones for "coverage" "profile"

#!/bin/bash
set -x
OPTS='--profile debug --flag --coverage'
fpm test $OPTS
OBJECT_DIR=$(dirname $(fpm build $OPTS --list 2>&1|grep '\.f90\.o$'|head -1))
gcov -r $OBJECT_DIR/src*.gcda 
exit

fpm-all      fpm-build       fpm-cdci      fpm-checkall
fpm-compute  fpm-coverage    fpm-describe  fpm-dict
fpm-ex       fpm-f90split    fpm-findll    fpm-flint
fpm-gdb      fpm-getpr       fpm-gprof     fpm-jsu
fpm-license  fpm-man         fpm-pck       fpm-place
fpm-plugins  fpm-rebuild     fpm-run       fpm-search
fpm-shell    fpm-standalone  fpm-time      fpm-tools

I have a bunch of them, but they are not generic enough fot distribution except a few like fpm-man, fpm-search, and fpm-gdb if you are a vim user. Was hoping to see plug-ins catch on more; but we really need to make an API for the model and build that can get things easily like the filenames and build directory and so on.

My gcov usage is very different; I did not know you could do it as simply as you illustrated.
https://github.com/urbanjost has the fpm-man, fpm-search which are pretty generic; and fpm-gdb for vim/gdb users if interested. If you flesh out a "coverage" plug-in, I would be interested in the results.