¿Método sugerido para extraer una biblioteca C independiente de un paquete R existente?

Mi grupo ha estado desarrollando un paquete R para simular el crecimiento de las plantas (ver el repositorio de GitHub ). El paquete R se usa .Callpara interactuar con C.

Hemos decidido que valdría la pena crear una biblioteca C independiente. Las dos razones clave son 1) usar herramientas de depuración de C familiares y 2) una gran parte de la comunidad de desarrolladores / usuarios está familiarizada con lenguajes compilados (la mayoría de los modelos de la clase están escritos en C o Fortran). Sin embargo, el paquete R es accesible para muchos fuera de esta comunidad, por lo que queremos mantener su funcionalidad.

He revisado algunas preguntas relacionadas, por ejemplo, https://stackoverflow.com/q/12328156/199217 , que discuten los paquetes R con las dependencias de la biblioteca C, pero no he encontrado una que se ocupe específicamente de desacoplar un paquete R existente.

Un enfoque propuesto

(lo que se nos ocurrió hasta ahora ... un hombre de paja)

1. Escribir pruebas para la funcionalidad existente
2. mantener la biblioteca C dentro de la src/carpeta
3. Coloque el código C específico de R (p SEXP. Ej. , Cargando bibliotecas R, etc.) en archivos 'R wrapper' antepuestos conR_*
4. crear funciones separadas para leer archivos de configuración en C
5. crear una función 'principal' C para reemplazar la funcionalidad en R
6. escribir un archivo MAKE para la biblioteca C que ignora los archivos de contenedor R
7. Una vez que la biblioteca C funciona de manera independiente y equivalente al paquete R, podríamos considerar mover las funciones C a un repositorio separado, eso sería una dependencia para el paquete R

Preguntas:

1. ¿Es este esfuerzo equivocado?
2. ¿Estamos pasando por alto posibles peligros?
3. ¿Hay una mejor manera de desarrollar las bibliotecas R y C en paralelo?
4. ¿Hay algún ejemplo de bibliotecas C que se hayan desacoplado de paquetes R?
5. ¿Cómo podríamos escribir pruebas para comparar funciones equivalentes en R y C?

En términos generales, esta es una buena idea y muchos paquetes lo hacen. Puede buscar RSQLiteinspiración: se empaquetan sqlitey solo incluyen algunas funciones de contenedor. Similar para rhdf5yhdf5

En cuanto a sus puntos:

Escribir pruebas para la funcionalidad existente

Siempre es una buena idea!

Mantenga la biblioteca C dentro de la src/carpeta.

Sí, o podría considerar inst/includesi alguna vez tomó la ruta de 'solo encabezado', a laRcpp

Coloque el código C específico de R (p SEXP. Ej. , Cargando bibliotecas R, etc.) en archivos 'R wrapper' antepuestos conR_*

Parece lo suficientemente sensible.

Crear funciones separadas para leer archivos de configuración en C

No estoy exactamente seguro de lo que quieres decir aquí.

Cree una función 'principal' C para reemplazar la funcionalidad en R

Esto me parece extraño. ¿Por qué necesita un main- no solo está desarrollando una biblioteca de funciones invocables? Deja que R sea tu main:)

Escriba un archivo MAKE para la biblioteca C que ignore los archivos de contenedor R

Sí, probablemente necesitará una mayor participación Makefilepara manejar esto; nuevamente sugiero que busque el código fuente de RSQLite, y también los R-exts pueden ser útiles.

Una vez que la biblioteca C funciona de manera independiente y equivalente al paquete R, podríamos considerar mover las funciones C a un repositorio separado, eso sería una dependencia para el paquete R

Sí, esto parece razonable: haga que el paquete R recupere el código fuente C según sea necesario al compilar / desarrollar el paquete. De esta manera se pueden desacoplar efectivamente.