Windows: Emulating win-builder (uses --force-multiarch)

[HenrikBengtsson]

If there's also an objective to emulate the win-builder service, then I pretty sure that one uses R CMD check option --mutiarch:

  --force-multiarch run tests on all sub-archs even for packages
                    with no compiled code

because also for packages using pure-R code, you'll get:

* checking examples ...
** running examples for arch 'i386' ... [12s] OK
** running examples for arch 'x64' ... [15s] OK
* checking for unstated dependencies in 'tests' ... OK
* checking tests ...
** running tests for arch 'i386' ... [168s] OK
[...]
** running tests for arch 'x64' ... [62s] OK

Note, however, from the CRAN check logs, it appear that the CRAN servers are NOT using --force-multiarch. So, I don't know how relevant it is to reproduce win-builder per se.

Background: I discovered this with a package where I get an error in the 'x64' tests, because the 'i386' tests generates some files that 'x64' tests don't expect to be there. In other words, the error does not appear if one run the two architechtures independently of each other (as one can do on AppVeyor).

[gaborcsardi]

Hmmm. I am not sure TBH.

In the worst case you can always add --force-multiarch using the check_args argument to check(). Isn't that good enough?

[HenrikBengtsson]

I tend to agree with you that there's little need to have rhub reproduce the win-builder services. This is more an issue with win-builder behaving differently than the CRAN test servers and one could argue that R CMD check should assert that there's no bleed-over from tests on one architecture to the following one. So, this should probably be reported to CRAN instead. And, in the end of the day, this is a bug in how the tests were written.

However, now it is at least documented in the wide open so if anyone else might find this from a web search.