[Rcpp-devel] Trouble with package unit test and sourceCpp()

Christian Gunning xian at unm.edu
Fri Sep 26 11:51:37 CEST 2014


Dirk,

This is a bit of a late response - I finally got back to this today.
I should have clarified that I'm using testthat and devtools.

I used the examples in RcppArmadillo to fix the path for compiling
code in tests, which is now working.  But I'm still running into what
appears to be the issue addressed here:
https://github.com/hadley/testthat/issues/144

test('RaggedArray') works fine, but "R CMD check RaggedArray" fails on
those same tests with the mysterious "cannot open file 'startup.Rs'"
error.  Output from "R CMD check RaggedArray":

* checking examples ... OK
* checking for unstated dependencies in tests ... OK
* checking tests ...
  Running ‘test_all.R’
 ERROR
Running the tests in ‘tests/test_all.R’ failed.
Last 13 lines of output:
  In file(filename, "r", encoding = encoding) :
    cannot open file 'startup.Rs': No such file or directory
  Execution halted

  Error in sourceCpp(system.file("tests", "userFun.cpp", package =
"RaggedArray")) :
    Error 1 occurred building shared library.
  Calls: test_package ... source_dir -> lapply -> FUN -> eval -> eval
-> sourceCpp

  WARNING: The tools required to build C++ code for R were not found.
  Please install GNU development tools including a C++ compiler.
  Execution halted

Any thoughts?
-Christian

On Wed, Sep 3, 2014 at 4:23 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 2 September 2014 at 20:42, Christian Gunning wrote:
> | I'm working on a package that includes a unit test that calls
> | sourceCpp() to test a particular use-case.
> [...]
> | My question is whether there's a sane workaround, or if I should give
> | up on these tests. Alternately, is there a cleaner way for a user to
> | supply hand-written C++ functions?  Using sourceCpp() allows the user
> | to locally manage custom functions without building a package, and
> | ensures that user edits aren't overwritten by a package upgrade.
>
> We do that in Rcpp itself, as well as in RcppArmadillo, RcppEigen, ...
> by using RUnit.  You should be able to use any of the other fine unit test
> packages too.
>
> Part of the logic is farmed out to a little helper function.  From the last
> one I worked on / added a few weeks ago for RcppArmadillo, ie
> rcpparmadillo/inst/unitTests/runit.sparse.R
>
>
>
> .runThisTest <- suppressMessages(require(Matrix))
>
> if (.runThisTest) {
>
>     .setUp <- RcppArmadillo:::unit_test_setup("sparse.cpp")
>
>     #
>     # tests follow below
>     #
> }
>
>
> and unit_test_setup() mostly deals with trying to get the path right:
>
>
>
> unit_test_setup <- function(file = NULL, packages = NULL) {
>     function(){
>         if (!is.null(packages)) {
>             for (p in packages) {
>                 suppressMessages(require(p, character.only = TRUE))
>             }
>         }
>         if (!is.null(file)) {
>             if (exists("pathRcppArmadilloTests")) {
>                 sourceCpp(file.path(get("pathRcppArmadilloTests"), "cpp", file))
>             } else if (file.exists(file.path("cpp", file))) {
>                 sourceCpp(file.path( "cpp", file))
>             } else {
>                 sourceCpp(system.file("unitTests", "cpp", file, package="RcppArmadillo"))
>             }
>         }
>     }
> }
>
>
> The cpp files themselves are then in cpp/ which is inside
> inst/unitTests/cpp.
>
> Dirk
>
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org



-- 
A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!


More information about the Rcpp-devel mailing list