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
Loading required package: methods
Loading required package: Rcpp
-IC:/R/win-library/2.12/QuadFunc/include
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.
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.
Thanks,
Jelmer