[Rcpp-devel] Some suggestions

Here are some suggested changes (under Windows) that will not affect
existing users but may help to prevent clashes with other packages in
the future.

1. RcppExport is not defined the way it used to be under Windows, but
there are situations where the old definition is convenient. For example,
it reduces the size of package DLL's the are not intended to be used
by other packages (the most common situation).

A simple work-around is to define RcppExportFinal the old way, using
something like:

#if defined(mingw32) || defined(WIN32)
#define RcppExportFinal extern "C" __declspec(dllexport)
#else
#define RcppExportFinal extern "C"
#endif

Let me know if/when you implement this so it does not clash with
the same definition in my package.

2. The current default behavior where a static lib is used
(libRcpp.a) is probably the most convenient and portable, but
there are situations where it is useful to link directly to Rcpp.dll.

To facilitate this one of the path functions in RcppLdpath.R
needs to be changed slightly for the case static=FALSE:

RcppLdFlags <- function(static=staticLinking()) {
     rcppdir <- RcppLdPath()
     if (static) {                               # static is default on
Windows and OS X
         flags <- paste(rcppdir, "/libRcpp.a", sep="")
         #if (.Platform$OS.type=="windows") {
         #    flags <- shQuote(flags)
         #}
     } else {                    # else for dynamic linking
         flags <- paste("-L", rcppdir, " -lRcpp", sep="") # baseline setting
         if((.Platform$OS.type == "windows")) {
           flags <- paste(rcppdir, "s/Rcpp.dll",sep="")
         }
         if ((.Platform$OS.type == "unix") &&    # on Linux, we can use
rpath to encode path
             (length(grep("^linux",R.version$os)))) {
             flags <- paste(flags, " -Wl,-rpath,", rcppdir, sep="")
         }
     }
     invisible(flags)
}

Dominick

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.

Also, does#if defined(mingw32) || defined(WIN32)

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.

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