[Rcpp-devel] [Rd] R inline package

Troy Robertson troy.robertson2 at bigpond.com
Mon Mar 19 06:50:31 CET 2012


At Dirks suggestion I have moved my question here to rcpp-devel

On 19/03/2012 9:54 AM, Dirk Eddelbuettel wrote:
> On 19 March 2012 at 09:32, Troy Robertson wrote:
> | I am having some problems with the inline package and maybe someone can
> | point out what is going wrong?
> | I have developed a C++ library to assist with an S4 R project I have
> | been working on for some time.  I need to be able to include my package
> | using the setCMethod() function but it fails to find library header
> | files and/or the Rcpp.h header if I include that.  Yet if I use the
> | cfunction call first, the exact same setCMethod() call will then work.
> | I am assuming the Rcpp plugin is being called because of the Rcpp=TRUE
> | argument to cfunction(), which is setting up the paths to cause the
> | success of the later setCMethod?  I know the setCMethod() call will work
> | without the includes argument, but I need to be able to add the include
> | to my library, which also fails unless the cfunction() call has been
> | made first.
> |
> | I am using R-2.14.1, Windows 7, inline (0.3.8), Rcpp (0.9.10).
> | I had to downgrade rTools to 2.14 because of the following problem I
> | encountered building my dll originally:
> |http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg03133.html
> |
> |
> | example:
> |
> | library(inline)
> | inc<-c("#include<Rcpp.h>");
>
> Never needed when you use cxxfunction(..., plugin="Rcpp") which is our
> idiomatic use.
I realise this #include is not required.  I was just using it to 
demonstrate my problem.
The same issue occurs if I drop the Rcpp.h include and replace it with 
an include for my library only.
> | sig<-signature(item="character")
> | code<-"return item;"
> | setCMethod("getSigItem", sig, body=code, includes=inc, Rcpp=TRUE,
> | verbose=TRUE)
> |
> | The above call fails with:
> | fatal error: Rcpp.h: No such file or directory
> |
> | The following call works fine:
> | f<-cfunction(sig, body=code, includes=inc, cppargs=cppa, libargs=liba,
> | Rcpp=TRUE, verbose=TRUE)
>
> Romain and I have made several changes to the inline package to support Rcpp,
> as well as a growing number of other packages, via so-called plugins -- and
> that uses the cxxfunction() which is essentially an extension of cfunction.
>
> I always use cxxfunction.  But then I don't usually build S4 methods with
> Rcpp, but I think some other people do.
Yes, I would like to create S4 methods using the setCMethod function if 
possible.
Has anyone else had success with this function and the use of includes?
>
> | And now the same setCMethod call from above will work:
> | setCMethod("getSigItem", sig, body=code, includes=inc, Rcpp=TRUE,
> | verbose=TRUE)
> |
> |
> | Thanks for any help you can provide
>
> I suggest you
>
>    a) try to disentangle your use of inline (== for testing) from your use of
>       Rcpp et al for package building
I have an R package (EPOC - Ecological modelling system) which allows 
users to create and add R code methods to extend the
functionality of existing S4 classes in a plug-and-play sort of way.  
This is all good.

I have now included C++ source in my package which builds to a shared 
library.  All fine, I can dyn.load my library and make
.Call(s) on it.

My aim is to now allow users of my package to create additional methods 
which contain inline C++ code which is able to take
advantage of the packages shared library.  This is where I am stuck.  
The striped back example above demonstrates the problem
without getting into the complexities of my modelling package or it's 
shared library.

Dirk, are you saying that inline should really only be used for testing 
or is my dynamic creation of setCMethod calls fit within
that definition?
Is anyone able to replicate the issue above or is it something wierd 
with my setup?

Thanks,
  Troy
>    b) come over to rcpp-devel and discuss things there
>
> Hope this helps,  Dirk
>
> -- "Outside of a dog, a book is a man's best friend. Inside of a dog, 
> it is too dark to read." -- Groucho Marx


More information about the Rcpp-devel mailing list