Creando un paquete r con un dll C++ en Windows y asegurando la portabilidad a Linux

Al trabajar en Windows, he creado un paquete r que enlaza con un dll C++ como biblioteca compartida. Esto funciona bien y se instala sin problemas en Windows. Cuando cambio a Linux, sin embargo, no se encuentra.Creando un paquete r con un dll C++ en Windows y asegurando la portabilidad a Linux

¿Estoy en lo cierto al pensar que el único archivo en el directorio src debería ser el archivo .cpp?

¿Realmente necesito ejecutar el comando SHLIB en ese directorio antes de crear el paquete?

En el espacio de nombres que utilizo:

useDynLib(myc.cpp,my.c.function)

y en la llamada de función:

my.r.f <- .Call(my.c.function, a, b)

En las ventanas que se ejecutan cheque R CMD funciona bien. ¿Podría ser la configuración de mi linux R la culpable? Parece instalar bien paquetes de terceros.

¡Estoy perplejo!

Fuente

2010-09-09 Chris Wheadon

No sé si encontrará una respuesta aquí, iré a la lista de correo de r-develop: [email protected] Si obtiene una respuesta, ¿le gustaría publicarla aquí como ¿bien? Esto es muy interesante para mí y para cualquier persona que escriba paquetes. –

@Joris El único problema es que Dirk Eddelbuettel a veces duerme ;-) – mbq

Creo que debería usar useDynLib(myc) ... La búsqueda de símbolos se realiza internamente.
EDITAR: La otra cosa es el nombre de este archivo de objeto: creo que el archivo MAKE estándar solo lo nombra con el nombre del paquete, por lo que debería ser más bien useDynLib(<package name>). Al menos siempre me funciona.

Fuente

2010-09-09 12:40:31 mbq

Al agregar 'PACKAGE =" my.package.name "' a cada '.Call' se evitará la búsqueda de símbolos para cada llamada de función. –

¿Estás seguro? Pensé que era para evitar conflictos de nombres, mientras que R optimiza la búsqueda con algún diccionario que se actualiza según las peculiaridades de la plataforma y los argumentos de dyn.load. Pero no estoy seguro en absoluto. – mbq

"búsqueda de símbolos" es probablemente la frase incorrecta.No recuerdo el comportamiento exacto, pero incluir el argumento 'PACKAGE 'impidió una búsqueda que aumentara drásticamente la velocidad de las llamadas repetidas a' .Call'. Pudo haber sido 'getCallingDLL' o' getDLLRegisteredRoutines' ... –

Existen cientos de paquetes en CRAN que hacen con éxito lo que intenta hacer: compilar un paquete con fuentes que se compilarán en cualquiera de las plataformas admitidas.

Una estrategia que me gusta es tomar uno o más paquetes existentes y ver exactamente cómo están configurados. A continuación, puede copiar la receta de trabajo según cómo corresponda a su configuración (con o sin NAMESPACE, con o sin biblioteca externa como libxml, etc. pp_)

Fuente

2010-09-09 13:33:05

Seguí los consejos de Dirk y busqué algunos paquetes en CRAN.

Un enfoque común parece ser utilizar el useDynLib (package_name) como lo sugiere mbq en el archivo NAMESPACE. Luego utilicé la llamada:

.Call("my.c.function", a, b, package="package_name")

en el código R según lo sugerido por Joshua.

Ahora instala y funciona bien en Linux y Windows :-)

Creo que pronto voy a cambiar a RCPP como herramientas de compilación y construcción de paquetes esqueleto de R-un aspecto muy atractivo.

¡Gracias a todos!

Fuente

2010-09-12 20:18:29

Creando un paquete r con un dll C++ en Windows y asegurando la portabilidad a Linux

Respuesta

Cuestiones relacionadas