[Rd] R CMD check ignores .Rbuildignore?

[Ross Boylan]

On Mon, Mar 19, 2007 at 11:33:37AM +0100, Martin Maechler wrote:
> >>>>> "RossB" == Ross Boylan <ross at biostat.ucsf.edu>
> >>>>>     on Sun, 18 Mar 2007 12:39:14 -0700 writes:
> 
>     RossB> The contents of .Rbuildignore seems to affect
>     RossB> R CMD build
>     RossB> but not 
>     RossB> R CMD check.
> 
>     RossB> I'm using R 2.4.0 on Debian.
> 
>     RossB> Is my understanding correct?  
> 
> yes.  That's why it's called 'buildignore'.
> It's a big feature for me as package developer:
It's more of a bug for me :(.  I was thinking of check as answering
the question "If I build this package, will it work?"
> 
> E.g., I can have extra tests (which e.g. only apply on my
> specific platform) in addition to those which are use when the
> package is built (to be checked on all possible platforms).
> 
> Some have proposed to additionally define a '.Rcheckignore' 
> but they haven't been convincing enough.

How about an option to have check use the buildignore file?  If there
are 2 separate files, there's always the risk they will get out of
sync.  Of course, in your case, you want them out of sync...

> 
>     RossB> And is there anything I can do about it?
> 
> "First build, then check" is one way;
> Something which is recommended anyway in some cases,
> e.g., if you have an (Sweave - based) vignette.
Kurt Hornick, offlist, also advised this, as well as noting that using
R CMD check directly on the main development directory isn't really
supported.

>From my perspective, needing to do a build before a check is extra
friction, which would reduce the amount of checking I do during
development.  Also, doesn't build do some of the same checks as check?

Minimally, I think some advice in the R Extensions manual needs to be
qualified:
In 
1.3 Checking and building packages
==================================

Before using these tools, please check that your package can be
installed and loaded.  `R CMD check' will _inter alia_ do this, but you
will get more informative error messages doing the checks directly.

---------------
There seem to be a couple of problems with this advice, aside from the
fact that it says to check first.  One problem is that the advice
seems internally inconsistent.  "Before using these tools" seems to
refer to the build and check tools in the section.  Since check is one
of the tools, it can't be used before using the tools.

Also, I still can't figure out what "doing the checks directly" refers
to.

Another section:
1.3.2 Building packages
-----------------------
[2 paragraphs skipped]

   Run-time checks whether the package works correctly should be
performed using `R CMD check' prior to invoking the build procedure.
------------------------
Since this advice, check then build, is the exact opposite of the
current recommendations, build then check, it probably needs to be
changed.

R CMD check --help (and other spots) refer to the command as
"Check R packages from package sources, which can be directories or
gzipped package 'tar' archives with extension '.tar.gz' or '.tgz'."  I
read this as referring to my source directory, although I guess other
readings are possible (i.e., package source = the source bundle as
distributed).

> 
>     RossB> In my case, some of the excluded files contain references to other
>     RossB> libraries, so linking fails under R CMD check.  I realize I could add
>     RossB> the library to the build (with Makevars, I guess), but I do not want
>     RossB> to introduce the dependency.
> 
> It depends on the circumstances on how I would solve this
> problem.... 
> [Why have these files as part of the package sources at all?]

I have 2 kinds of checks, those at the R level, which get executed as
part of R CMD check, and C++ unit tests, which I execute separately.
The latter use the boost test library, part of which is a link-time
library that ordinary users should not need.

All the C++ sources come from a web (as in Knuth's web) file, so the
main files and the testing files all get produced at once.

I worked around the problem by using the top level config script to
delete the test files.  I suppose I could also look into moving those
files into another directory when they are produced, but that would
further complicate my build system.

Ross