[Rd] Building Packages on Windows using .Rbuildignore (PR#7379)
ggrothendieck at myway.com
Sat Nov 20 04:47:50 CET 2004
Duncan Murdoch <murdoch <at> stats.uwo.ca> writes:
> On Sat, 20 Nov 2004 00:39:17 +0000 (UTC), Gabor Grothendieck
> <ggrothendieck <at> myway.com> 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.
> >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
> 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
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.
More information about the R-devel