http://www.keittlab.org/
On Sat, Feb 4, 2017 at 12:17 PM, Dirk Eddelbuettel <e...@debian.org> wrote:
>
> On 4 February 2017 at 11:58, Tim Keitt wrote:
> | Thanks.
> |
> | Here's what I came up with:
> |
> | Sys.setenv(R_TESTS = "")
> |
> | wd = getwd()
> | wd = sub(".tests.testthat$", "", wd)
> | ipath1 = file.path(wd, "inst", "include")
> | ipath2 = file.path(wd, "include")
> | Sys.setenv(PKG_CXXFLAGS = paste(paste0("-I", ipath1), paste0("-I",
> ipath2)))
> |
> | That works sometimes, but not always. It seems to pass R CMD check
> --as-cran
> | (still need to run on devel release), so that's what I needed. But oddly
> it
> | fails on apveyor and travis.ci. As far as I can tell, you cannot have
> any
> | confidence in the current working directory using testthat in different
> | environments.
>
> The "if you break it, you get to keep the pieces" saying comes to mind
> as we do not promise anywhere that testthat is in fact supported ...
>
Sure. Seems the issue is more with testthat than Rcpp anyway. I was just
posting in case someone else comes looking.
THK
>
> Stricly personally speaking, I have always found devtools and testthat
> too obfuscating for my liking. I build much smaller, simpler tools
> around littler. That works for me. And for unit tests, I still rely on
> RUnit. But that is just my view.
>
> If someone wants to work on (additonal, optional) support for
> testthat etc, the doors are always open for good pull requests.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
