R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

Being generally uninformed about Windows, I have to admit to almost
total confusion trying to follow this thread. However, since I have
recently been trying to do something in Windows, I would appreciate a
newbie friendly explanation of a few points:

-Rtools is used to build R and to build (some?) R packages. If you make
Rtools an R package, how do you bootstrap the R build process?

-in unix-like OSes, configure is used before make to set things similar
to the question of where to find Rtools, and what version of various
tools are available, and give warnings and errors if these are not
adequate. Is there a reason configure cannot be used in Windows, or is
there not something similar?

-or am I really confused and should not consider the possibility that
people actually build R, so the discussion is just about packages?

Thanks,
Paul

On 13-04-22 11:16 AM, Gabor Grothendieck wrote:

On Mon, Apr 22, 2013 at 10:27 AM, Duncan Murdoch
<murdoch.duncan at gmail.com> wrote:

On 21/04/2013 6:57 PM, Hadley Wickham wrote:

PS. Hadley, is this what you meant when you wrote "Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *.", or those approaches are only when you call 'R CMD'
from the R prompt?  I believe the latter, but I just want to make sure
I didn't miss something.

Well both devtools and RStudio allow you to do package development
without leaving R, so neither do anything to your path when you're not
using them.

In teaching windows users to develop R packages, I found the use of
the command line to be a substantial road-block, and if you can
develop packages without leaving R, why not?

The idea of temporary additions to the path during the INSTALL/build/check
code sounds reasonable.  R could probably do it more accurately than
devtools or RStudio can (since we know the requirements, and you have to
guess at them), but could hopefully do it in a way that isn't incompatible
with those.

The code called by install.packages() and related functions within R is
essentially the same code as called by R CMD INSTALL etc from the command
line, so this would help both cases.

I would like to comment on this as I have had to implement similar
facilities myself as part R.bat in the batchfiles.

There is an issue of keeping R and Rtools in sync.   Currently
different Rtools versions will work with the same R version.  For
example, I have used both Rtools 1927 and 1930 with the current
version of R.  Its necessary to determine the relative paths that the
version of Rtools in use requires since in principle the relative
Rtools paths can vary from one version of Rtools to the next if the
gcc version changes, say.

Ideally the system would be able to figure this out even if registry
entries and environment variables are not set by looking in standard
locations for the Rtools root and finding the relative paths by
querying some file in the Rtools installation itself.  devtools does
this by querying the Rtools version and uss an internal database of
relative paths keyed by version.   R.bat in batchfiles does it by
scanning the Rtools unins000.dat file and extracting the relative
paths directly from it.  This has the advantage that no database need
be maintained and it also automatically adapts to new versions of
Rtools without any foreknowledge of them.   Of course since you have
control of both ends you alternately could add the relative paths to
an expanded version of the VERSION file or add some additional text
file into Rtools for the purpose of identifying he relative paths..

Another possibility if significant changes were to be considered would
be to make Rtools into an R package thereby leveraging existing
facilities and much simplifying any synchronization.

--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com