On Mon, Mar 19, 2007 at 11:33:37AM +0100, Martin Maechler wrote: > >>>>> "RossB" == Ross Boylan <[EMAIL PROTECTED]> > >>>>> 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
