kevinushey
Files that registerFunctions registers
It would be nice if one could tell registerFunctions which functions to register since you might want to keep some of them private while having others public, i.e. you might not wish to register all of them. Perhaps it could input a pattern and only filenames matching that pattern would be scanned for functions to register. For example, we might only want those filenames of the form "^extern_.*\\.cpp$" to be scanned.
I am not sure if I understand -- registerFunctions expects the user to have explicitly adorned functions with // [[register]] attributes, so only functions with that attribute on top get registered*.
*also, functions within RcppExports.cpp are registered since I figured that is usually what is desired.
Sorry. I didn't understand that. If there is a package that uses this can you point it out - an actual example of it in action would be helpful.
I use it in Kmisc itself :) But the process isn't completely automated. The basic idea is, when I want to build the package, I do:
Rcpp::compileAttributes()
Kmisc::registerFunctions()
and then do the regular R CMD build, R CMD INSTALL. This process auto-generates the RcppExports.cpp file (as per Rcpp::compileAttributes()) and also Kmisc_init.c (giving the call method defs). Presumedly this could be easily automated using configure and cleanup, although I have not done so.
Note that this only works for functions using the .Call interface, though.
But I think the above only works as explained if you do
Kmisc::registerFunctions(prefix = "")
as otherwise what gets registered is C_packagename_functionname , but the RcppExports.cpp file has definitions for packagename_functionname and RcppExports.R has .Call('packagename_functionname', blablabla).
Alternatively, if I simply use
Kmisc::registerFunctions()
then I need to edit the RcppExports.R file to have .Call('C_packagename_functionname', blablabla).
I wonder if I am doing something silly.
The registration work disables dynamic symbol lookup. Unfortunately this means that the R wrappers generated by compileAttributes() will no longer work and so you need to generate your own.
Perhaps this script could be 'nice' and fix up an associated RcppExports.R file when run?
"so you need to generate your own." Always? Maybe I am not following here, but in some very limited testing I did, just doing Kmisc::registerFunctions(prefix = "") and not touching anything seemed to work.
As for having a nicer script: that would be nice. But in the meantime maybe adding a paragraph to the documentation of registerFunctions would be enough. For instance, something like "If you want to combine the usage of registerFunctions with Rcpp's compileAttributes, run compileAttributes first. Then, run registerFunctions (all functions within RcppExports.cpp are automatically registered, so you do not need to add //[[register]] to those). Finally, edit the RcppExports.R file; locate each of the usese of .Call, and prefix the name of the .Call'ed function(s) with "C_", or with whatever else you used as the prefix argument to registerFunctions".
But then, couldn't compileAttributes do all of the work and by default also register? I guess I am missing something here, but registration I think is highly recommended for BioC packages and also welcome in CRAN packages so I am not sure about the downsides of this.