Skip to content
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

Rcpp/fortran support? #9

Closed
hadley opened this issue Jan 6, 2015 · 17 comments
Closed

Rcpp/fortran support? #9

hadley opened this issue Jan 6, 2015 · 17 comments

Comments

@hadley
Copy link
Member

hadley commented Jan 6, 2015

Is there any chance you might be able to combine covr with an existing C++ code coverage tool in order to also give C++ code coverage stats?

@jimhester
Copy link
Member

Yeah that is something I want to add, I had a few links in #4 about it. Should be able to use https://gcc.gnu.org/onlinedocs/gcc/Gcov.html with a little work.

@jimhester
Copy link
Member

I believe the same flags -fprofile-arcs -ftest-coverage should also work with for fortran code as well.

@jimhester jimhester changed the title Rcpp support? Rcpp/fortran support? Jan 7, 2015
@hadley
Copy link
Member Author

hadley commented Jan 7, 2015

Looks like it's built into llvm: http://www.llvm.org/docs/CoverageMappingFormat.html

@jimhester
Copy link
Member

@hadley what is the preferred way to pass compiler flags to devtools::load_all()? I tried adding

  old <- devtools:::set_envvar(c(CFLAGS = "-fprofile-arcs -ftest-coverage", CXXFLAGS = "-fprofile-arcs -ftest-coverage", FFLAGS = "-fprofile-arcs -ftest-coverage"), "prefix")
  on.exit(devtools:::set_envvar(old), add = TRUE)

before covr.R#L181 which does set CFLAGS, CXXFLAGS, and FFLAGS environment variables, but those values don't seem to be used when compiling. (The flags from devtools::compiler_flags() also seem to be ignored). I tried compiling dplyr and devtools, in both cases the environment variables don't seem to be used.

Am I doing something obviously wrong, or is there an alternative method we need to use to force the profiling flags?

@jimhester
Copy link
Member

the answer to the above is you need to use PKG_CFLAGS PKG_CXXFLAGS etc. I think this is also a bug in devtools::compiler_flags() as well.

@hadley
Copy link
Member Author

hadley commented Jan 7, 2015

Do you have latest devtools? There was a problem previously - I'm pretty use CFLAGS etc is the right choice because it's for user overrides on the compilation of all packages .PKG_CFLAGS etc is for options for a specific package.

@jimhester
Copy link
Member

devtools * 1.6.1.9000 2014-12-30 Github (hadley/devtools@6192843)

It may be that the packages I have tested against all define PKG_CFLAGS variables in Makevars so they are overriding the values in CFLAGS. In which case devtools is probably ok.

@jimhester
Copy link
Member

preliminary support is now on master via 572d3da.

Outstanding issues

  • complier optimization needs to be at -O0 as lines can get optimized out completely which makes the output impossible to interpret.
  • source files which are not run at all by tests will not get counted as uncovered.
  • need to verify gcov is available on windows.

@jimhester
Copy link
Member

So the only real issue I am running into here is forcing R to use -O0 when compiling. From @eddelbuettel's answer at http://stackoverflow.com/a/23414789/2055486 it seems like the only way to override the default CFLAGS is by adding values to ~/.R/Makevars. Doing that temporarily seems hacky, but I don't really see another way to go unless there is another way to override the values. Setting the CFLAGS environment variable has no effect.

@eddelbuettel
Copy link

From memory, I may have seen something lately in R NEWS changes (which I read daily via RSS) that they allow overriding now. Hitherto $RHOME/etc/Makeconf always won making this an issue. Not really sure if it changed, but may be worth checking with R-devel.

@jimhester
Copy link
Member

Ok I will look around some more and see if I can find anything, thanks Dirk!

On Thu, Jan 8, 2015 at 2:52 PM, Dirk Eddelbuettel notifications@github.com
wrote:

From memory, I may have seen something lately in R NEWS changes
http://developer.r-project.org/blosxom.cgi/R-devel (which I read daily
via RSS) that they allow overriding now. Hitherto $RHOME/etc/Makeconf
always won making this an issue. Not really sure if it changed, but may be
worth checking with R-devel.


Reply to this email directly or view it on GitHub
#9 (comment).

@jimhester
Copy link
Member

As of 18d9210 this is now working locally by using a subprocess R session, but failing when trying to use R CMD check or on travis, possibly because of issues mentioned in r-lib/testthat#144. I added `R_TEST="" and NOT_CRAN="true" and it got further, but there is still an issue of some kind. Will keep trying though!

@jimhester
Copy link
Member

Ok now seems to be working on everything but covr itself. Here is an example of the digest package.

https://coveralls.io/builds/1749592

@helske
Copy link
Contributor

helske commented Feb 28, 2015

I see that this works for C/C++, but for some reason coveralls does not check the Fortran code in my package: https://coveralls.io/r/helske/KFAS

I am new to both Travis and Coveralls so it might be just me. Any hints?

@helske
Copy link
Contributor

helske commented Mar 2, 2015

Tested this also locally on Linux, I compiled with -O0 and changed package Makevars to
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) -fprofile-arcs
PKG_FCFLAGS = -fprofile-arcs -ftest-coverage

This seems to make the necessary gcov files but package_coverage still does not report any info about .f95 files.

@jimhester
Copy link
Member

@helske this is because the function used to detect source files does not find extension .f95 like you used in your project. https://github.com/jimhester/covr/blob/master/R/compiled.R#L81-L82. It needs to be updated to handle all of the common FORTRAN extensions, http://fortranwiki.org/fortran/show/File+extensions seems like a decent list.

Right now the only FORTRAN extension that is found is .f

@helske
Copy link
Contributor

helske commented Mar 3, 2015

Thanks, should have figured that out by debugging the code a bit. I updated the compiled function (and package_coverage) accordingly and created a pull request: #64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants