[Rd] Building Packages on Windows using .Rbuildignore (PR#7379)

Gabor Grothendieck ggrothendieck at myway.com
Fri Nov 19 15:28:29 CET 2004


Duncan Murdoch <murdoch <at> stats.uwo.ca> writes:

: 
: On Thu, 18 Nov 2004 19:32:25 +0100, Martin Maechler
: <maechler <at> stat.math.ethz.ch> wrote:
: 
: >>>>>> "Duncan" == Duncan Murdoch <murdoch <at> stats.uwo.ca>
: >>>>>>     on Thu, 18 Nov 2004 16:36:03 +0100 (CET) writes:
: >
: >    Duncan> On Thu, 18 Nov 2004 00:38:47 +0000 (UTC), Gabor
: >    Duncan> Grothendieck <ggrothendieck <at> myway.com> wrote :
: >
: >    >> DIFFERENCE BETWEEN USING .RBUILDIGNORE AND NOT
: >    >> 
: >    >> The reason that the processing is different according to
: >    >> whether one uses .Rbuildignore or not is that R CMD build
: >    >> takes the .Rbuildignore file into account but R CMD
: >    >> install R CMD check R CMD build --binary do not take
: >    >> .Rbuildignore into account.
: >
: >    Duncan> Okay, now I understand.  I think I'd call the last
: >    Duncan> of those a bug, and it would seem to me that the
: >    Duncan> install and check scripts should also respect this
: >    Duncan> directive.  I've now copied this to the r-bugs list.
: >
: >    Duncan> (This was reported for Windows; I don't know if it
: >    Duncan> applies to other platforms as well.)
: >
: >Yes it does (*), but I think it is NOT a bug but a feature,
: >at least for "check" and "install" (*) 
: >and very much desired in some cases :
: >
: >For instance, the package developer may want more
: >regression tests in <Pkg>/tests/ :
: >
: >1) Have extra *.Rout.save files that are architecture
: >   dependent and hence not for general distribution of the
: >   package, but important for the package developer in order to
: >   assure that functionality doesn't change when the package is
: >   extended, reorganized, ....
: >
: >2) Have more  tests/*.R  files  that take a long time to run.
: >   Time that the package developer wants to spend, but doesn't
: >   dare to put on the daily CRAN or Bioconductor test suites.
: >
: >3) similarly for vignettes
: >
: >4) similar issues for experimental  R/*.R files  or man/*.Rd
: >   files for these.
: >
: >One I thing that would be quite useful and would even solve
: >Gabor's problem: 
: >The introduction of a new command line switch, say "--build-ignore",
: >to the commands 'R CMD check' and 'R CMD install'
: 
: Shouldn't that option be "--ignore-build-ignore"? 
: 
: More seriously:  I suspect that an on/off switch for the .Rbuildignore
: file wouldn't be sufficiently flexible: the same package author might
: want different things at different times, e.g. building a binary for
: Windows would include different files than a binary for another
: platform.  We could put together some sort of system of conditionals
: within the .Rbuildignore file, but I think it would be better to just
: advise such package writers to maintain one or more .Rbuildignore.in
: files, and manually (or by makefile) copy the appropriate one in place
: first.

That would be useful if there are several excluded files: a.R, b.R
and c.R and one wants to force inclusion of just a.R and b.R, say, but
continue to exclude c.R.   One could make a temporary copy
of .Rbuildignore, edit it to no longer exclude a.R and then use
R CMD as usual with the new switch/flag.

During development this could be quite useful as one tests out
different combinations in the presence or absence of other
files.

An even more elaborate design of this would be to have --include= and 
--exclude= switches/flags in which one can specify specific patterns
to include or exclude or @myfile to get them from a file.

Some typical examples might look like:
--exclude=@myfile     (gets file from same directory as .Rbuildignore)
--exclude=@.\myfile   (gets file from current directory
--exclude=@\myfile    (gets file from root directory)
--include="a.R|b.R"   (excludes all in .Rbuildignore except a.R and b.R)
--exclude=.Rbuildignore (this is the default)

Not sure how much work that is to implement but I can see it being
useful.



More information about the R-devel mailing list