[Rd] R CMD check problem with R 3.0.2

[Yihui Xie]

I understand these reasons, and they certainly make sense when a
package has a big/complicated src/ directory. Perhaps one day more
developers will move the building and checking to cloud services (e.g.
I have been using Travis CI), so nobody cares about the
building/checking time spent on local machines any more.

For now, I think either `R CMD check --build` (must build before
checking) or `R CMD check --force` (definitely check without building)
sounds like a reasonable solution.

Regards,
Yihui
--
Yihui Xie <xieyihui at gmail.com>
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Mon, Oct 28, 2013 at 12:40 PM, Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>>>>>> Duncan Murdoch <murdoch.duncan at gmail.com>
>>>>>>     on Sun, 27 Oct 2013 08:56:31 -0400 writes:
>
>     > On 13-10-26 9:49 PM, Simon Urbanek wrote:
>     >> On Oct 25, 2013, at 12:12 PM, Yihui Xie wrote:
>     >>
>     >>> This has been asked soooo many times that I think it may
>     >>> be a good idea for R CMD check to just stop when the
>     >>> user passes a directory instead of a tar ball to it, or
>     >>> automatically run R CMD build before moving on. In my
>     >>> opinion, sometimes an FAQ and a bug are not entirely
>     >>> different.
>     >>>
>     >>
>     >> +1 -- and I'd do the same for R CMD INSTALL. If someone
>     >> insists, there could be --force or something like that
>     >> for those that really want to work on directories despite
>     >> all the issues with that, but IMHO the default should be
>     >> for both INSTALL and check to bail out if not presented
>     >> with a file -- it would save a lot of people a lot of
>     >> time spent in chasing ghost issues.
>
>     > That seems like a reasonable suggestion.  I wouldn't want
>     > to lose the ability to install or check a directory; for
>     > development of packages like rgl which have a lot of
>     > compiled code, installing from a tarball takes a lot
>     > longer than installing when all of the code has already
>     > been compiled.
>
> Even more extreme for  Matrix, and as you mention other packages
> with a considerable portion of compiled code.
>
> R CMD build also does some checks that then are done again, when
> you  R CMD check the tarball.
> It really adds a considerable amount of time/work to have to do
> both and I'd strongl oppose to disable checking of the source
> directory of a package.
>
> Actually, I do think that the 'build/check' R code could and should be
> modularized so that checking a directory with an 'Authors at R' in DESCRIPTION
> ((and no 'Maintainer'/'Authors' as they are auto-created)) would
> still work fine...
>
>
>     > On the other hand, it isn't all that hard to put together
>     > an R function or shell script to do it (the hardest part
>     > is figuring out the name of the tarball).  For example:
>
>     > installpkgdir <- function(dir) {
>     > x <- system(paste("R CMD build", dir), intern=TRUE)
>     >  ....
>     > }
>
>     > I haven't tested this much, and it doesn't offer options
>     > to the build or install steps, but it could be the basis
>     > of a simple function that always builds a tarball before
>     > installing a source directory.
>
> well, there have been other ways to bundle  "build + check", of
> course, but for some developers, package building really is not fast,
> notably for people like me with a large library of R packages,
> where the all dependent packages incl those in 'Suggests' are
> sought and checked for the correct version, etc.
> Also, by default the vignette rebuilding; manuals etc take time,
> and it used to need other manual manipulations if you disabled those,
> and then wanted to check the tarball.
>
> I'd be very much inconvenienced if I'd need to build packages
> every time I want to check them during development.  Things are
> different shortly before a release.
>
> Martin