c - tseries - instalar paquetes en r

Paquete R que enlaza a la biblioteca C externa

Question

Tengo un código c que utiliza la biblioteca igraph . Me gustaría poner un envoltorio R alrededor y enviarlo a CRAN como un paquete R.

igraph ya tiene un puerto R en CRAN, por lo que tendría sentido que mi paquete ''R'' dependiera del igraph de R. Como foo usa su propio código C que depende del gráfico, ¿cómo puedo vincular mis funciones C a la biblioteca igraph original? He leído que esto se hace en un archivo llamado Makevars, pero el enlace a una biblioteca externa es muy delicado.

Si esto no es posible, ¿es mejor copiar todo el código fuente de igraph y ponerlo en mi directorio / src? El paquete R igraph ya tiene un archivo llamado Makevars, pero no entiendo cómo se construyen todos los archivos c. Normalmente, en mi Makefile tengo algo como gcc (alguna lista de archivos fuente .c) -o, pero Makevar solo contiene

PKG_CFLAGS=-DUSING_R -I. -Ics -Iglpk -Iglpk/amd -Iglpk/colamd /
-g -O2 -I/usr/include/libxml2 -g -O2 -I/usr/include/libxml2 -DNDEBUG /
-DPACKAGE_VERSION=/"0.6/" -DINTERNAL_ARPACK /
-DIGRAPH_THREAD_LOCAL=/**/
PKG_CXXFLAGS= -DUSING_R -DIGRAPH_THREAD_LOCAL=/**/ -DNDEBUG
PKG_LIBS=-lxml2 -lz -lpthread -licucore -lm -lgmp  $(FLIBS) $(LAPACK_LIBS) $(BLAS_LIBS)

all: $(SHLIB)

y no hay otro Makefile. En resumen, ¿cómo hago para colocar el código C en un paquete R que depende de otra biblioteca C y cómo escribo los Makevars correspondientes (o Makefile) para incorporar las funciones C?

here se publicó una pregunta anterior here pero solo parece vincularse con la ayuda para escribir su propio código C que no depende de nada.

Answer 1

Hay varias preguntas aquí:

1. ¿Puede un paquete ''foo'' enlazar de manera confiable a un paquete ''bar''? "Writing R Extensions", al principio de la Sección 5.8 en "Enlace a otros paquetes" dice "no, no en general", como Gabor insinuó también en su comentario anterior.

2. El código fuente de C puede colocarse en un paquete para construir un paquete que depende de otra biblioteca: sí, por supuesto, y muchos paquetes en CRAN lo hacen. Elija, por ejemplo, un ejemplo de un paquete según la GSL, o las bibliotecas de gráficos JPEG / TIFF, o XML, o ... Puede estudiar estas fuentes. Eso no es trivial más fácil, pero si estudia estos paquetes, la documentación que se encuentra en Writing R Extensions y las demás respuestas a las preguntas relacionadas que debe encontrar aquí, debe llegar allí.

Answer 2

Tomo una lectura ligeramente diferente de "Writing R Extensions". El párrafo 1 de la Sección 5.8.1 (que trata con sistemas operativos similares a Unix) dice que es posible, pero no portátil o recomendable, vincular a una biblioteca compartida . El párrafo 2 dice que las bibliotecas estáticas están bien (el ''Esto'' al principio del párrafo es confuso; ¿a qué se refiere?) Porque la biblioteca estática proporcionada por packA puede ser descubierta por packB cuando se instala packB, y luego se incorpora a la biblioteca dinámica. Esto requiere que packA proporcione una biblioteca estática, y por lo tanto, packA se dio cuenta de que su función era hacer esto; muchos paquetes, en cambio, pensarán que su función es proporcionar una interfaz R a un subconjunto de la funcionalidad de la biblioteca que envuelven, y proporcionan un objeto compartido que enlaza con la biblioteca compartida en su propio paquete.

Un ejemplo es el paquete Rsamtools en Bioconductor, que crea versiones estáticas de la biblioteca samtools y proporciona un mecanismo (complicado para obtener el derecho) para los paquetes que desean acceder a la biblioteca estática (una vignette proporciona una vista de paquete dependiente de las cosas). Es importante proporcionar la ruta absoluta a la biblioteca estática PKG_LIBS="-l$(PKGB_PATH)/libpackB.a" para evitar la vinculación estática a la misma biblioteca provista por el sistema (con los encabezados proporcionados por packA).

@DirkEddelbuettel casi seguramente ha ido por este camino, y señalará mis errores. Estoy de acuerdo con su comentario a continuación de que el uso de una biblioteca estática es subóptimo (¿principalmente desde la perspectiva del consumo de memoria?), Pero tome la decisión de evitar los motivos de portabilidad mencionados en el párrafo 5.8.1.