On Sat, Jul 10, 2010 at 4:46 AM, Romain Francois <[email protected]>wrote:
> Hello, > > First of all I'm not sure what all of this buys us, so I'd be somehow > reluctant to change something that works without understanding what we gain > and what we lose. > Why is this important/relevant for you. You say "there are situations where > it is useful to link directly to Rcpp.dll". Please describe. > This is more a matter of completeness than new functionality. Currently if you use Rcpp:::LdFlags(static=FALSE) under Windows you will not get the shared library, so this option doesn't apply to Windows. WIth the change I suggested you would get Rcpp/libs/Rcpp.dll in this case. I am not suggesting that the casual user should use this option, but at least Rcpp:::LdFlags() does something reasonable when passed the FALSE option under Windows. This is not really that important, but it could be if/when you have many clients, for the same reason that having R.dll is important: all clients can link to the same image (provided it is not rebased). BTW, on the Linux side there is double redundancy: not only is there Rcpp.so and libRcpp.a (containing the same code), but there is also libRcpp.so, which is exactly the same as Rcpp.so. Disk space is cheap, but at the rate new features are being added to Rcpp this may become an issue at some point. | Also, the dll is built anyway, so your client package is free to link against it, i.e. we provide |Rcpp:::LdFlags for convenience but if other packages want to use something else, that's ok too. Why |can't you just alter you configure/Makevars so that they link against the dll ? Yes, of course, this can be implemented on the client side, and this leads to the second reason for my post. I wanted to raise these issues to give you the opportunity to add functionality that properly belongs to Rcpp, and that could conflict with client defs if they are added to Rcpp later. > Also, does#if defined(mingw32) || defined(WIN32) > take care of windows 64 ? > I think so, unless they add mingw64 and WIN64... Dominick
_______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
