[R] Basic package structure question

[Joerg van den Hoff]

Prof Brian Ripley wrote:
> On Fri, 23 Jun 2006, Joerg van den Hoff wrote:
> 
>> just to confirm duncan murdochs remark:
>>
>> our Windows machines lack proper development environments (mainly
>> missing perl is the problem for pure R-code packages, I believe?) and we
>> bypass this (for pure R-code packages only, of course) by
>>
>> 1.) install the package on the unix machine into the desired R library
>> 2.) zip the _installed_ package (not the source tree!) found in the R
>>           library directory
>> 3.) transfer this archive to the Windows machine
>> 4.) unzip directly into the desired library destination
>>
>> this procedure up to now always worked including properly installed
>> manpages (text + html (and I hope this remains the case in the future...)
> 
>  From README.packages:
> 
>   If your package has no compiled code it is possible that zipping up the
>   installed package on Linux will produce an installable package on
>   Windows.  (It has always worked for us, but failures have been reported.)
> 
> so this is indeed already documented, and does not work for everyone.
> 
albeit sparsely...

AFAIKS it's not in the `R Extensions' manual at all. If(!) this approach 
could be made an 'official' workaround and explained in the manual, that 
would be good.

I'd appreciate if someone could tell me:

are the mentioned failures confirmed or are they "UFOs"?

if so, are (the) reasons for (or circumstances of) failure known (I'm 
always afraid walking on thin ice when using this transfer strategy)?

what does "produce an installable package on Windows" in the README text 
mean? I presume it does not mean that R CMD INSTALL (or the Windows 
equivalent) does work? if it really means "unzip the package on the 
Windows machine into the library directory", should'nt the text be altered?

and I forgot to mention in my first mail: I use the described procedure 
for transfer from a non-Intel apple machine under MacOS (a FreeBSD 
descendant) to Windows (and even (unneccessarily, I know) to 
Sun/Solaris). so the strategy is not restricted to transfer from Linux 
-> Windows.

and it is useful (if it is not 'accidental' that it works at all): in 
this way one can keep very easily in sync several local incarnations of 
a package across platforms (if network access to a common disk is not 
the way to go): I simply `rsync' the affected (local, R-code only) 
library directories.