[Rcpp-devel] Re-using C++ code from a package with modules and defining linker flags using Rscript
jelmerypma at gmail.com
Mon May 16 21:47:14 CEST 2011
yes, this makes sense, thanks. I originally added the CxxFlags(),
because one of the packages I'm linking to defines where to find the
Boost headers, but I see that it's not needed in all cases.
On Mon, May 16, 2011 at 15:26, Dirk Eddelbuettel <edd at debian.org> wrote:
> Hi Jelmer,
> On 16 May 2011 at 14:00, Jelmer Ypma wrote:
> | Hi Dirk,
> | thanks for your reply.
> | > PS Also try
> | >
> | > -e "QuadFunc:::CxxFlags()")
> | >
> | > instead of
> | >
> | > -e "library(QuadFunc); QuadFunc:::CxxFlags()")
> | >
> | > as the ::: finds unexported symbols, that usually works from unloaded
> | > packages too.
> | It works for unloaded packages that don't use modules. Since QuadFunc
> | uses modules, this results in an error
> | > Rscript -e "QuadFunc:::CxxFlags()"
> | Error: .onLoad failed in loadNamespace() for 'QuadFunc', details:
> | call: value[[3L]](cond)
> | error: failed to load module QuadraticFunctionModule from package QuadFunc
> | Execution halted
> | whereas loading the library first doesn't
> | > Rscript -e "library(QuadFunc); QuadFunc:::CxxFlags()"
> | Loading required package: methods
> | Loading required package: Rcpp
> | -IC:/R/win-library/2.12/QuadFunc/include
> I see, and I stand corrected. Using modules may have that requirement as a
> | Perhaps I'm mis-using modules and should change something in my
> | NAMESPACE or in R/zzz.R to get rid of this error? You can get the same
> | error using Rcpp.package.skeleton( 'testmodA', module=TRUE ) (see the
> | first email).
> | > And because of LinkingTo: QuadFunc you may not need the CxxFlags.
> | This is correct in this case. If another package links to QuadFuncVec,
> | then I think the dependencies become a bit more complicated (but I
> | might be mistaken here). Either the new package needs to add QuadFunc
> | to the LinkingTo: field, or QuadFuncVec:::CxxFlags() should return the
> | flags of all its dependencies. In this case I would choose to
> | implement QuadFuncVec:::CxxFlags() returning its own flags and those
> | from QuadFunc:::CxxFlags(). That way the user has to worry a bit less
> | about dependencies. At least, that was what I came up with after some
> | experimentation yesterday.
> It should does not hurt. But for the compile step, you should only need the
> header files, and R itself can point to those via LinkingTo.
> Having a CxxFlags() function allows you to set other flags (maybe
> -Dsomething) if you need it. Nothing wrong with that -- I was merely trying
> to point that you could make your life a little simpler.
> | Are the LinkingTo: fields obtained for the current package only, or
> | also the LinkingTo: fields of the packages it links to also included?
> | E.g. packB has LinkingTo: packA, packC has LinkingTo: packB. Are the
> | include paths of packA automatically added to packC? That would make
> | the CxxFlags() unnecessary in this case.
> I don't believe the DESCRIPTION files of dependent packages are read. So I
> would just do this in DESCRIPTION for packC:
> LinkingTo: packA, packB
> Does that help?
> | Thanks,
> | Jelmer
> Gauss once played himself in a zero-sum game and won $50.
> -- #11 at http://www.gaussfacts.com
More information about the Rcpp-devel