Hi Dirk, 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.
Thanks! Jelmer On Mon, May 16, 2011 at 15:26, Dirk Eddelbuettel <e...@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 > side-effect. > | > | 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? > > Dirk > > | > | Thanks, > | Jelmer > > -- > Gauss once played himself in a zero-sum game and won $50. > -- #11 at http://www.gaussfacts.com > _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
