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

[Duncan Murdoch]

On 29/04/2013 7:43 AM, Paul Gilbert wrote:
> 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?

Rtools used to be needed for all packages.  Nowadays packages that 
consist only of R code typically wouldn't need it.

It might be possible to make Rtools into an R package, but it would 
require quite a bit of work, because generally speaking packages don't 
provide command line executables, and we strongly prefer packages to 
contain their own source.  The Rtools source is really quite huge (since 
it contains compilers for C/C++, Fortran, and Objective C/C++, as well 
as a small collection of Unix-like tools).
>
> -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?

Most bare-bones Windows systems can't run configure scripts and could 
not possibly provide the minimal tools necessary to build R, so we 
decided long ago to manually configure R for one particular toolset, 
which we maintain and distribute.

People who have Cygwin installed can use the usual Unix-style tools to 
configure R for Cygwin, but as far as I know no Cygwin maintainer has 
managed to build R so that it passes its tests.  We (in R-core) do not 
support Cygwin, putting our efforts towards the current strategy instead.


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

Not very many people build R on Windows, but a few do, and we support 
them by making Rtools available.

Duncan Murdoch

>
> 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
> >