My group has been developing an R package to simulate plant growth (see GitHub repository). The R package uses .Call to interface with C.We have decided that it would be worthwhile to create a standalone C library. The two key reasons are 1) to use familiar C debugging tools and 2) a large portion of the developer / user community is familiar with compiled languages (mostly models in the class are written in C or Fortran). However, the R package is accessible to many outside this community, so we want to maintain its functionality.I have reviewed some related questions, e.g. https://stackoverflow.com/q/12328156/199217, that discuss R packages with C library dependencies, but have not found one that deals specifically with decoupling an existing R package.A proposed approach(what we have come up with so far ... a strawman)Write tests for existing functionalitykeep the C library inside the src/ folderPlace R-specific C code (e.g. SEXP, loading R libraries, etc) into 'R wrapper' files prepended with R_*create separate functions for reading configuration files in Ccreate a 'main' C function to replace functionality in Rwrite a makefile for the C library that ignores R wrapper filesOnce the C library works independently and equivalently to the R package, we could consider moving the C functions to a separate repository, that would be a dependency for the R packageQuestions:Is this effort misguided?Are we overlooking any potential pitfalls?Is there a better way to develop both the R and C libraries in parallel?Are there any examples of C libraries that have been decoupled from R packages?How might we write tests to compare equivalent functions in R and C?
Suggested method for extracting a standalone C library from an existing R package?
design;testing;c;refactoring;r
Generally speaking, this is a fine idea and many packages do this. You might look at RSQLite for inspiration -- they package up sqlite and just include some wrapper functions. Similar for rhdf5 and hdf5Regarding your points:Write tests for existing functionalityAlways a good idea!Keep the C library inside the src/ folderYes -- or you could consider inst/include if you ever went the 'header-only' route, a la RcppPlace R-specific C code (e.g. SEXP, loading R libraries, etc) into 'R wrapper' files prepended with R_*Seems sensible enough.Create separate functions for reading configuration files in CNot exactly sure what you mean here.Create a 'main' C function to replace functionality in RThis seems odd to me. Why do you need a main -- aren't you just developing a library of callable functions? Let R be your main :)Write a makefile for the C library that ignores R wrapper filesYes, you will probably need a more involved Makefile to handle this -- I again suggest looking at the source code for RSQLite, and also R-exts may be helpful.Once the C library works independently and equivalently to the R package, we could consider moving the C functions to a separate  repository, that would be a dependency for the R packageYes, this seems sensible -- have the R package retrieve the C source code as necessary when building / developing the package. This way they can be effectively decoupled.