[Rcpp-devel] RcppOctave on Windows: testing needed

[Dirk Eddelbuettel]

Dominick,

Thanks for the detailed email, the follow-up is appreciated.  A few quick
additions below as some questions were raised:

On 5 October 2013 at 17:44, Dominick Samperi wrote:
| Hello Renaud,
| 
| Here is a summary of my testing results.
| 
| 1. Your binary and source distribution is currently setup to use DLL's instead
|     of static libs. This is tricky to do under Windows, and this is why Rcpp
|     provides a static lib to link against. You may want to consider using
|     the same convention to avoid the complications explained below.

Indeed, the use of this 'deploy a static library for simplicity' shortcut is
acknowledged. We do it because it works reliably (and people struggle enough
already with Rtools and what have you when working on Windows), but the
resulting binaries/libraries are sadly rather HUGE.

And of course if we had a foolproof way to build with DLLs we would.  But as
you say: "tricky". Possibly too tricky too ever get there.
 
| 2. Your binary installs fine under Windows 7, but when RcppOctave is
|     loaded and then R is terminated, I get the unhelpful Windows error
|     message: "This application has requested the Runtime to terminate
|     it in an unusual way." I get the same failure when I try to build from
|     source at the point where R CMD INSTALL tries to test the ability
|     to load the package. The solution (not obvious from the message!)
|     is to simply add the directory containing Rcpp.dll to PATH.
|     The next item explains why.
|
| 3. Under normal circumstances when package Foo loads
|     its own Foo.dll, what happens is that R reads the dll directly and
|     does not depend on Windows to resolve dependencies on other
|     R package dll's. But in the case of RcppOctave.dll, there is a dependency
|     on Rcpp.dll, and Windows will not resolve this dependency unless
|     the directory containing Rcpp.dll is on PATH (another strategy is to
|     place Rcpp.dll in a Windows System directory, but this is not
|     consistent with the R install process and is not recommended).

Correct. 

When I test on Windows, particularly with RInside, I sometimes cheat and copy
various required DLLs into the current directory. We normally do not need to
do this for R packages as R takes care of loading its shared libraries, but
when embedding R into Octave, this aspect may need to be covered. Maybe the
Rcpp DLL directory needs to be appended to the DLL search path for Octave?

[ We also 'cheat' a little on Linux by embedding the shared library location
via rpath. That is not ideal as it breaks things once you move libraries
(which is why rpath is more or less forbidden by use of distributions) but as
R uses private shared library locations we just do it regardless. ]
 
| 4. The parameter _WIN32_WINNT is set to a value used to identify
|     the underlying Windows OS version (2000, XP, 7, 8, etc.), and it
|     is set differently in the gcc configuration used to build Octave and
|     the one found in Rtools. I don't know if this makes a difference
|     that matters. In general, there is the potential for ABI problems
|     since Octave and Rtools use different versions of gcc. To be safe I
|     guess you could build Octave using the gcc from Rtools.

Seconded. A bit of a pain as you would need to rebuild Octave, and even more
of a pain when you want to redistribute.  Years ago I created some (simple)
(in-house, at work) real-time plotting / charting apps via Qt that also used
R, and I "simply" resolved to rebuilding Qt from source using the Rtools
build chain. Not elegant, but that is the price one pays on Windows when
using gcc -- which is a compiler common to 'all of us' but really not common
for the Windows world at large.  So mixing and matching with other object
code is just so much harder on Windows.
 
| 5. On the recommended order of including RcppCommon.h vs Rcpp.h,
|     I have implemented custom wraps a few times with only Rcpp.h
|     included (at the top). This seems to work with rcpp_octave.h as well.
|     I would like to see a simple example where
|     the recommended order is necessary. Is this recommendation
|     insurance against some future change? Does it apply specifically
|     to user customized modules (as suggested by wrap_end.h)?

Oh, I can see the possible confusion.  But I do not recall that we ever said
one could include only RcppCommon.h.  I think the only time we talk about
RcppCommon is in the context of as<>() and wrap() implementations where it is
an effective forward declaration of 'all things Rcpp'.  The best official
word on what to do is still the Rcpp-extending vignette.  But include is
finicky which is why we now test in RcppArmadillo.h whether Rcpp.h has
already been loaded -- it should not. One should include just RcppArmadillo.
And in almost all cases one wants just one include in client projects:
Rcpp.h.  But as<>() and wrap() happen to be an exception. 

Contributions to better/clearer documentation would of course be appreciated.

Hope this helps,  Dirk

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com