[R-sig-dyn-mod] Using dynamically compiled code for use with deSolve in a new package
Hi Thomas, Thanks. Package building works now. However, when running a check, I get: * checking compiled code ... NOTE File 'secsse/libs/i386/secsse.dll': Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols' File 'secsse/libs/x64/secsse.dll': Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols' Where should I have made these calls? Furthermore, I get: * checking if this is a source package ... WARNING Subdirectory 'src' contains: dimmod.mod I did not create this file, so don't know where this is coming from. Do you have any clue? Cheers, Rampal
On 30-Nov-17 09:43, Thomas Petzoldt wrote:
[off-list] ... but roxygen2 **can** write the useDynLib line itself: #' @useDynLib foo Thomas Am 30.11.2017 um 09:09 schrieb Rampal S. Etienne:
Hi Thomas, Thanks. I got it to work. The solution was to not let roxygen do the namespace file, as it overwrites the line containing useDynLib. Cheers, Rampal On 29-11-2017 23:30, Thomas Petzoldt wrote:
Hi, including Fortran and/or C sources in /src is exactly what we (and the other CRAN authors) do. It is self-evident, that binary code (like dlls) cannot be included in portable packages, that are expected to run on different operating systems. Details are found in "Writing R Extensions". I don't see a problem with roxygen2, this is exactly how it was implemented in package "growthrates", mentioned earlier. Let's assume we have a package called "foo", add the following roxygen-directives to a file "R/foo-package.R": #' @useDynLib foo #' #' @importFrom deSolve ode Hope it helps, Thomas On 29.11.2017 14:44, Rampal S. Etienne wrote:
Dear Thomas, Thanks again for this reply. While this may work locally and for some users, it does not work in my case where my namespace file is generated by roxygen2. Also, CRAN does not like dll-file to be in the package (inst folder), so it needs to be built at installation. How do I do this? Simply including the Fortran code in the src directory does not work (gives error 127, whatever that is). Any suggestions? Cheers, Rampal On 11-6-2017 21:15, Thomas Petzoldt wrote:
Hi, that's straightforward. 1) Put deSolve in Depends of your package DESCRIPTION: Depends: deSolve 2) Import the solver function (e.g. ode or lsoda) in the NAMESPACE of your package and declare your dynamic library (.dll or .so) importFrom(deSolve,ode) useDynLib(mypackage) 3) and then use this .dll/.so in the call to ode(): ode(...., dllname = "mypackage", .....) An example can be found in package growthrates: https://github.com/tpetzoldt/growthrates/blob/master/pkg/R/grow_twostep.R Hope it helps, Thomas On 11.06.2017 13:20, Rampal Etienne wrote:
Dear all, I have written C and FORTRAN functions to use with deSolve and found that it works significantly faster than the analogous R functions. So far so good! However, now I want to build a package that uses this code. How do I do this? I can include the DLL in the package (so no more compilation by the user of the package, just loading it), but then the user needs to be able to find it. Where will this be installed? That may be different on different systems. Any suggestions? Cheers, Rampal