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

Paul Gilbert pgilbert902 at gmail.com
Mon Apr 29 13:43:22 CEST 2013


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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



More information about the R-devel mailing list