[Rcpp-devel] [Rd] R inline package

[Troy Robertson]

On 19/03/2012 12:50 PM, Troy Robertson wrote:
> 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

Okay, after having a look at the source for the inline package, I see 
that ... arguments to setCMethod()
are not passed on in its internal call to cfunction(), hence my cppargs 
and libargs (and indeed Rcpp=TRUE)
are ignored?

Troy