Kevin Ushey: (12:10AM on Fri, Jun 07)
I think the key word here is _other_ packages. It's entirely okay to call
your package's own compiled code through the .Call interface (and the code
you write may link to other packages; the obvious example being Rcpp code
you write); however, it is not porta
Dear Kevin, Berwin and Gabriel,
Thank you very much for your detailed and clear answers.
According to your comments, in a few days I will submit my package to CRAN.
I would also like to take this opportunity to thank all the R-devel list
for being a wonderful place to discuss and clarify doubts
I think the key word here is _other_ packages. It's entirely okay to call
your package's own compiled code through the .Call interface (and the code
you write may link to other packages; the obvious example being Rcpp code
you write); however, it is not portable to use .Call to call compiled code
f
Guillermo,
That phrase is referring to using .Call in your package to call a C
function that shipped with a DIFFERENT package or is part of R itself
(defined in the R source code).
As long as you are only calling C functions you define in the C++ code that
ships with your package you are fine.
~
Dear R-devel list,
I am creating an R package that includes C++ code. I tried to install it
both in Linux and Windows and it worked. I load the C code via the
NAMESPACE file using useDynLib.
Now I am revising once again whether everything is ready before
submitting the package to CRAN and I have