[R-pkg-devel] Help with Windows build failure

[Dirk Eddelbuettel]

On 2 April 2017 at 17:21, Alexandre Sieira wrote:
| Hi, everyone.
| 
| I have done some work this weekend to allow the SnakeCharmR package (
| https://github.com/asieira/SnakeCharmR) to be compiled under Windows. For
| reference, this is an Rcpp-based packages that links to the system's
| libpython.
| 
| I have been able to test it on my box using Windows 10 and several Python
| versions:
| 
| * Rtools mingw_64/opt Python 2.7.9;
| * python.org 2.7.13 64-bit;
| * python.org 3.6.1 64-bit;
| * python.org 2.7.x 32-bit on Appveyor (
| https://ci.appveyor.com/project/asieira/SnakeCharmR).
| 
| Still, when I submit my source package to win-builder I get an error:
| https://win-builder.r-project.org/9aqdlW0D6e3m/
| 
| https://win-builder.r-project.org/9aqdlW0D6e3m/00install.out shows some
| warnings on header files that are outside of my control, but ends with a
| successful compilation. However, it compiles only the 64-bit version of the
| DLL and gives me this warning:
| 
| Warning: this package has a non-empty 'configure.win' file,
| so building only the main architecture
| 
| 
| Finally, when we look at
| https://win-builder.r-project.org/9aqdlW0D6e3m/00check.log we see an error
| due to the fact that the package can’t be tested on i386:
| 
| ** checking whether the package can be loaded ... ERROR
| Loading this package had a fatal error status code 1
| Loading log:
| Error: package 'SnakeCharmR' is not installed for 'arch = i386'
| Execution halted
| ** DONE
| Status: 1 ERROR, 1 NOTE
| 
| 
| I apologize if this is a beginner’s problem, but this is my first R package
| ever and I’m not really used to working with R on Windows. Would appreciate
| any guidance and pointers on how to address this and get the package to
| pass the necessary CRAN automated tests.

I tried to make Python and R co-exist at some point; my conclusion was there
aren't enough days in the week to figure out how to do it on Windows.  It's
easy to do on Linux, and I don't personally have OS X / macOS use cases but
here it's feasible if you're careful about your toolchain.

I think you should just consider 'OS_type: unix' in your DESCRIPTION.  A
working and uploaded package on two OSs beats an "almost there but never
finished" package on three in my book.

Dirk

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