[Rcpp-devel] On Developing Header Packages
JJ Allaire
jj.allaire at gmail.com
Tue Apr 7 20:51:18 CEST 2015
I think that header-only packages (where possible) are definitely
preferable within the R package ecosystem because it allows you to
sidestep a lot of build configuration and runtime linking complexity.
The rub is that some libraries simply can't be made header-only,
especially if they make use of static data. I was able to convert the
TinyThread library to header-only by simply prefacing all
function/method definitions with the inline keyword. However that was
a pretty small library so I'm not sure you'd have the same easy time
of it with a larger library like clBLAS.
On Tue, Apr 7, 2015 at 2:37 PM, Charles Determan <cdetermanjr at gmail.com> wrote:
> This is probably the best place I can think of to ask this question if
> perhaps not completely on topic. Some quick context:
>
> I am exploring GPGPU computing and with my 'open-source' mindset I quickly
> gravitated to using OpenCL. Thankfully, many wonderful programmers have
> already begun creating libraries to make this language better and faster.
> One such library is the clBLAS library which essentially implements BLAS
> routines for OpenCL enabled devices. Naturally, I would like to use this
> library but I don't like the idea of telling users to install a dependency
> outside of R and would rather have them install another package. Therefore,
> I have it in my head to create a header package for the clBLAS library to be
> used by anyone exploring OpenCL programming within R.
>
> This leads me to my two general questions that I hope others can comment.
>
> 1. What are developers thoughts regarding the 'packaging' of various C++
> header libraries? I know this has be very successfully done with the 'BH'
> package but is this considered an exception or an example?
>
> 2. If it is encouraged to create such header packages are there any
> guidelines or standards that should be followed? Is there an expected
> structure? I can look at the 'BH' package and go from there but it would be
> nice if the R(cpp) community had some collective opinion about this.
>
> Regards,
> Charles
>
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
More information about the Rcpp-devel
mailing list