[Rcpp-devel] Some suggestions

[romain at r-enthusiasts.com]

Le 10 juil. 2010 à 15:16, Dominick Samperi <djsamperi at gmail.com> a écrit :

> On Sat, Jul 10, 2010 at 4:46 AM, Romain Francois <romain at r-enthusiasts.com> 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.

Ah ok. It is worth testing it. 

Feel free to patch it and send it to win builder. Unit tests in runit.client.package.r test that clienr packages work. I suppose this could be extended to test if static = FALSE works


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

Yes. Eventually what we would like is for R to take over the details as part of "LinkingTo : Rcpp" ... Maybe one day, until then the system works, so we dont want to change it.


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

Sure

> Also, does#if defined(mingw32) || defined(WIN32) 
> take care of windows 64 ?
> 
> I think so, unless they add mingw64 and WIN64...
> 
> Dominick

I prefer evidence rather than guesses, as i do not enjoy debugging on windows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20100710/041e6ecc/attachment.htm>