[R] Basic package structure question
murdoch at stats.uwo.ca
Fri Jun 23 13:15:54 CEST 2006
On 6/23/2006 5:45 AM, Joerg van den Hoff wrote:
> 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?
I do not want to support more than one method of installing packages.
The R CMD install method works. If some other method also works, it's
One obvious limitation of this install method is that it won't produce
native Windows help files (.chm). Plans are to make CHM the default
help system as of the 2.4.0 release, so your packages will not work
properly unless you give special instructions on how to change the help
The other obvious limitation is that it won't work if you have any C or
Fortran code in your package.
> 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.
You might be able to achieve this by doing your builds on Windows,
rather than on Linux or MacOS, but as far as I know it is not possible
to build .chm files on those OSs.
More information about the R-help