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

From: Gabor Grothendieck <>
Date: Sat 20 Nov 2004 - 14:47:50 EST

Duncan Murdoch <murdoch <at>> writes:

> On Sat, 20 Nov 2004 00:39:17 +0000 (UTC), Gabor Grothendieck
> <ggrothendieck <at>> wrote:
> >: Even with this change, Rcmd check is still going to install the files
> >: it's supposed to ignore, because it uses Rcmd INSTALL, and there's no
> >: .Rbuildignore support there.
> >:
> >
> >If the behaviour is suddenly changed then this is going to cause work
> >for people whose scripts depend on the current behavior.
> Yes, that's normal. If you work around a bug and the bug gets fixed,
> then you will need to change your code. That's why the NEWS file
> reports bug fixes and other changes.
> > In order to
> >minimize disruption I would ask that such change only be made at the
> >same time that a flag for turning on and off .Rbuildignore processing
> >is implemented on build, check, install and build --binary.
> There's a simple workaround to turn .Rbuildignore processing off: just
> rename the file. Adding a switch is *not* a prerequisite for the
> other changes.
> >Even
> >with such a flag it may require revision to scripts but at least
> >any change with the flag will be minimal. Even better, it may
> >mean some scripts can be eliminated.
> There are 3 changes that I would contemplate:
> 1. Fix the bug that means "R CMD check" looks in the wrong place for
> .Rbuildignore.
> 2. Make "R CMD build --binary" consistent with "R CMD build" in its
> handling of .Rbuildignore.
> 3. Make "R CMD install" and "R CMD check" consistent with "R CMD
> build" in their handling of .Rbuildignore.
> Number 1 should definitely be fixed in the patches to 2.0.1. I have a
> feeling that both 2 and 3 should be done (and 2 would be an automatic
> consequence of 3 unless we took action to stop it), but I'd put them
> in 2.1.0, not 2.0.x.
> Martin and you have also suggested
> 4. Add another flag to Rcmd build (and install and check?), to turn
> .Rbuildignore processing on and off, for increased flexiblity or for
> backward compatiblity.
> My own feeling is that this doesn't increase flexibility enough, and
> I'd like a better solution, but we've got lots of time before 2.1.0 is
> released to discuss this.

I did not know it was a bug and even you did not realize it until you looked at the code.

I do have one suggestion that might be trivial for you yet be beneficial for everyone else, as an interim step, until a better solution comes about.

After fixing the scripts, could you leave the old scripts in bin with new names, e.g. oldbuild, oldcheck, etc. so that one can issue the command:

   R CMD oldbuild ...

and get the old behavior. That provides a simple way to get either behavior while waiting for the ultimate solution and does not interfere with the new scripts in any way. mailing list Received on Sat Nov 20 14:53:42 2004

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:01:38 EST