Gabor Grothendieck wrote: > On 6/22/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> Jay Emerson wrote: >>> At the encouragement of many at UseR, I'm trying to build my first real >>> package. I have no C/Fortran code, just plain old R code, so it should be >>> rocket science. On a Linux box, I used package.skeleton() to create a basic >>> package containing just one "hello world" type of function. I edited the >>> DESCRIPTION file, changin the package name appropriately. I edited the >>> hello.Rd file. Upon running R CMD check hello, the only warning had to do >>> with the fact that src/ was empty (obviously I had no source in such a >>> simple package). I doubt this is a problem. >>> >>> I was able to install and use the package successfully on the Linux system >>> from the .tar.gz file, so far so good! Next, on to Windows, where the >>> problem arose: >>> >>> I created a zip file from inside the package directory: zip -r ../hello.zip >>> ./* >>> >>> >> Which package directory, the source or the installed copy? I think this >> might work in the installed copy, but would not work on the source. >> It's not the documented way to build a binary zip, though. >>> When I moved this to my Windows machine and tried to install the package, I >>> received the following error: >>> >>> >>>> utils:::menuInstallLocal() >>>> >>> Error in unpackPkg(pkgs[i], pkgnames[i], lib, installWithVers) : >>> malformed bundle DESCRIPTION file, no Contains field >>> >>> I only found one mention of this in my Google search, with no reply to the >>> thread. The Contains field appears to be used for bundles, but I'm trying >>> to create a package, not a bundle. This leads me to believe that a simple >>> zipping of the package directory structure is not the correct format for >>> Windows. >>> >>> Needless to say, there appears to be wide agreement that making packages >>> requires precision, but fundamentally a package should (as described in the >>> documentation) just be a collection of files and folders organized a certain >>> way. If someone could point me to documentation I may have missed that >>> explains this, I would be grateful. >>> >> I think the "organized in a certain way" part is actually important. >> Using R CMD install --build is the documented way to achieve this. It's >> not trivial to do this on Windows, because you need to set up a build >> environment first, but it's not horribly difficult. >> >> Duncan Murdoch >>> Regards, >>> >>> Jay > > One idea that occurred to me in reading this would be to have a server > that one can send a package to and get back a Windows build to > eliminate having to set up a development environment. Not sure if > this is feasible, particularly security aspects, but if it were it would > open up package building on Windows to a larger audience. > > ______________________________________________ > R-help@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
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...) joerg van den hoff ______________________________________________ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html