I’m trying to detect coverage testing flags in CMake before passing them to gfortran using
check_fortran_compiler_flag(). This works fine on Linux (GCC 9.4.0). With MinGW64 on Windows, some flags aren’t detected (GCC 10.2.0). I suspect this might be an issue with the underlying test not finding
libgcov but that’s speculation; I don’t know why it’s failing.
In the process of diagnosing this problem, I manually built sample code with a variety of options (
-ftest-coverage) under both the Windows command shell and under MSYS2’s version of
bash. The build process was essentially
gfortran <options I'm testing> -o mytest mytest.f && mytest but with environment-specific paths, file extensions, etc.
Here’s the weird part: running gfortran from the same directory as
mytest.f succeeds under both
bash. If I run gfortran against
mytest.f in a different directory (say
bash puts the coverage files in the directory gfortran was run from. Running this under
cmd puts the files in the directory containing the source file. I’m not doing anything weird with environment variables (that I know of) and I’m running the exact same gfortran executable in both cases, literally invoking the same file and path.
The GCC docs say that the coverage files will be placed in the same directory as the object files. My tests originally just specified the input
.f file and the result executable with
-o. Breaking the build process into separate compilation and executable generation steps shows that object files are created in the source directory under
cmd and in the compilation directory under
bash. That’s consistent with the original tests.
This leaves me wondering if CMake’s fortran compiler flag checking is being affected by gfortran’s inconsistency in where it writes object files by default.
The workaround is to completely skip option checking, just assume
--coverage works, and manually change the options if
--coverage fails. Not great but it’s a step forward.
So the main questions are what’s the cleanest way to resolve this and has anyone seen this behavior before? Failing that, how do I get more visibility of what CMake actually invokes from the call to