On 12.04.2012 01:16, Paul Gilbert wrote:
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.
No, this is all done automatically by R CMD build, hence you do not need
to worry.
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,
Well, yours are that specific that they rely on third party software.
Vignettes "only" depending on R and installed packages that are declared
as dependencies can be build by CRAN.
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.)
R CMD build will rebuild vignettes unless you ask R not to do so.
Uwe
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
