[Rcpp-devel] Re-using C++ code from a package with modules and defining linker flags using Rscript

[Jelmer Ypma]

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 <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
> 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
>