On Sun, Jul 11, 2010 at 12:06 PM, Romain Francois <[email protected]>wrote:
> Le 11/07/10 17:51, Dominick Samperi a écrit : > >> On Sun, Jul 11, 2010 at 4:58 AM, Romain Francois >> <[email protected] <mailto:[email protected]>> wrote:Le >> >> 11/07/10 02:14, Dominick Samperi a écrit : >> >> Romain, >> >> I made two small changes that should have no impact at all since >> they only >> apply when you build using windows DLL's (not static libs). >> Obviously these >> are not tested by a win-builder submission. >> >> >> Why not. >> >> >> Because testing this would require PATH to be changed at CRAN to include >> the directory containing Rcpp.dll, and this must be done BEFORE the >> package >> build or check process. This would have to be done using a Windows batch >> file as part of the initialization. Doing it in configure.win will not >> work. Also, >> a real test would require another package (like cxxPack) that links >> against >> Rcpp dynamically. >> > > As I said, check the runit.client.package.R test that does exactly this: > checking that a client package works. > > We do test that documented ways to include Rcpp headers and link against > the user libraries work. > > While on the subject, the current best way to pull header files in is to > use LinkingTo: Rcpp and not: > > PKG_CPPFLAGS = $(shell $(R_HOME)/bin/Rscript --vanilla -e > "Rcpp:::CxxFlags()") > > which is what several packages are still using, including cxxPack. > Why are you telling me what I obviously already know? Your reply does not address any of the points that I raised here about Windows dynamic linking. In particular, runit.client.package.R does not address these issues at all (only the STATIC library libRcpp.a is used). Dominick
_______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
