When developing packages, authors can use .Rbuildignore to remove unneeded files / folders when building a package tarball. However, I have found in a few cases that the rules I define in this file strip out files that I didn't expect it to.
This is, of course, my fault since R-exts 1.3.2 is very clear on how .Rbuildignore is used (perl-like regular expressions), but could R potentially be helpful and warn the user if files are removed that typically would / should not be?
My example is R scripts (.r, .R) residing within the R/ subdirectory of a package. I think it's unlikely that users would want to strip R files out of this directory when building a tarball, but a poorly written .Rbuildignore could strip those files out, and cause unexpected errors on installation. Similarly, I imagine users typically would not want .cpp, .c, .f, etc. files stripped out of the src/ subdirectory. Another example is the build/ directory.
This is mostly because other errors observed later can be hard to diagnose without understanding that .Rbuildignore can, and will, strip these files as well.
It doesn't seem particularly easy for R CMD build to recognize when a programmer didn't mean to write what they wrote, but it does sound reasonable to allow a "verbose" option that reports on which files are being ignored.
So then if you get a perplexing "function not found" kind of error, you can rebuild with the verbose option and see what exactly happened during the build.
However, the hard part of writing verbose options is deciding exactly what should be reported. There are a lot of steps in R CMD build, and each of them might be doing something that should be reported to the user under a verbose option. So this looks like a lot of work. I don't think I'll volunteer to do it...
Actually, I will volunteer to do this, i.e. to add a --verbose option.
.Rbuildignore does not 'remove' files: it omits them from the tarball.