Context: R2.15-0 on Ubuntu.
1. I get a WARNING from CMD check for "Package vignette(s) without
corresponding PDF:
In this case the vignettes directory had both the pdf and Rnw; do I
need to move the pdf to inst/doc?
I'm reluctant to add the pdf to the svn source on Rforge, per the
usual rule that a code management system should not have both a primary
source and a object dervived from it under version control. However, if
this is the suggested norm I could do so.
2. Close reading of the paragraph about vignette sources shows the
following -- I think? If I have a vignette that should not be rebuilt
by "check" or "BUILD" I should put the .Rnw source and pdf
in /inst/doc,
and have the others that should be rebuilt in /vignettes. This would
include any that use "private R packages, screen snapshots, ...", or
in
my case one that takes just a little short of forever to run.
3. Do these unprocessed package also contribute to the index via
\VignetteIndexEntry lines, or will I need to create a custom index?
Terry Therneau
For 1, you should run R CMD check on the tar ball (pkg_x.x.tar.gz) from R CMD build instead of the source directory. R CMD build will build the PDF vignette into the tar ball. For 2, I have been confused by ./vignettes vs ./inst/doc since ./vignettes was introduced. I might be able to figure it out by try-and-err but I never tried, and I'm still sticking to ./inst/doc. At least you can exclude the Rnw source in .Rbuildignore so that R can only stare at your PDF documents and sigh. For 3, I remember some of us requested that R could also respect entries of non-Sweave vignettes (like the ones in ./demo/00Index), but this is not possible as far as I know. However, I can tell you a dark voodoo seems to be still working: you can write your own index.html under ./inst/doc with your own links to vignettes. Regards, Yihui -- Yihui Xie <xieyihui at gmail.com> Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, Apr 11, 2012 at 3:41 PM, Terry Therneau <therneau at mayo.edu> wrote:> Context: R2.15-0 on Ubuntu. > > 1. I get a WARNING from CMD check for "Package vignette(s) without > corresponding PDF: > ?In this case the vignettes directory had both the pdf and Rnw; do I need to > move the pdf to inst/doc? > > ? I'm reluctant to add the pdf to the svn source on Rforge, per the usual > rule that a code management system should not have both a primary source and > a object dervived from it under version control. ?However, if this is the > suggested norm I could do so. > > 2. Close reading of the paragraph about vignette sources shows the following > -- I think? ?If I have a vignette that should not be rebuilt by "check" or > "BUILD" I should put the .Rnw source and pdf in /inst/doc, and have the > others that should be rebuilt in /vignettes. ?This would include any that > use "private R packages, screen snapshots, ...", or in my case one that > takes just a little short of forever to run. > > 3. Do these unprocessed package also contribute to the index via > \VignetteIndexEntry lines, or will I need to create a custom index? > > Terry Therneau > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On 12-04-11 04:41 PM, Terry Therneau wrote:> Context: R2.15-0 on Ubuntu. > > 1. I get a WARNING from CMD check for "Package vignette(s) without > corresponding PDF: > In this case the vignettes directory had both the pdf and Rnw; do I need > to move the pdf to inst/doc?Yes, you need to put the pdf in the inst/doc directory if it cannot be built by R-forge and CRAN check machines, but leave the Rnw in the vignettes directory.> > I'm reluctant to add the pdf to the svn source on Rforge, per the usual > rule that a code management system should not have both a primary source > and a object dervived from it under version control. However, if this is > the suggested norm I could do so.Yes, I think this is the norm if the vignette cannot be built on CRAN and R-forge, even though it does seem a bit strange. However, you do not necessarily need to update the vignette pdf in inst/doc every time you make a change to the package even though, in my opinion, the correct logic is to test remaking the vignette when you make a change to the package. You should do this testing, of course, you just do not need to put the new pdf in inst/doc and commit it to svn each time. (But you should probably do that before you build the final package to put on CRAN.)> > 2. Close reading of the paragraph about vignette sources shows the > following -- I think? If I have a vignette that should not be rebuilt by > "check" or "BUILD" I should put the .Rnw source and pdf in /inst/doc, > and have the others that should be rebuilt in /vignettes. This would > include any that use "private R packages, screen snapshots, ...", or in > my case one that takes just a little short of forever to run.I don't think it is intended to say that, and I didn't read it that way. I think putting the Rnw in inst/doc is supported (temporarily?) for historical reasons only. If it is not in vignettes/ and is found in inst/doc/, it is treated the same way as if it were in vignettes/. You can include screen snapshots, etc, in either case. For your situation, what you probably do need to do is specify "BuildVignettes: false" in the DESCRIPTION file. This prevents the pdf for inst/doc from being generated by the the Rnw. However, it does not prevent R CMD check from checking that the R code extracted from the Rnw actually runs, and generating an error if it does not. To prevent testing of the R code, you have to appeal directly to the CRAN and R-forge maintainers, and they will put the package on a special list. You do need to give them a good reason why the code should not be tested. I think they are sympathetic with "takes forever to run" and not very sympathetic with "does not work anymore". Generally, I think they want to consider doing this only in exceptional cases, so they do not get in a situation of having lots of broken vignettes. (One should stick with journal articles for recording broken code.)> 3. Do these unprocessed package also contribute to the index via > \VignetteIndexEntry lines, or will I need to create a custom index?I'm not sure of the answer to this, but would be curious to know. You may need to rely on voodoo. Paul> > Terry Therneau > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel