From tomas.kalibera at gmail.com  Fri Dec  8 13:14:21 2017
From: tomas.kalibera at gmail.com (Tomas Kalibera)
Date: Fri, 8 Dec 2017 13:14:21 +0100
Subject: [Rd] Bug: Issues on Windows with SFN disabled
In-Reply-To: <23081.30486.281015.895433@bud.eddelbuettel.com>
References: <CAD7tZLXB=73wY9tqLmYhTXyBB9DMO1WZXGz3U9pHz9KgEX4K=Q@mail.gmail.com>
 <34ec506d-bec1-544f-9067-2109bd0db1e5@gmail.com>
 <93be1744-51e7-7d97-ee08-cb16857b79a2@gmail.com>
 <e17103b5-b473-6dac-7de4-1df157f973d2@gmail.com>
 <23081.30486.281015.895433@bud.eddelbuettel.com>
Message-ID: <4209816d-b26c-519a-0880-2b51512b609c@gmail.com>

On 12/07/2017 06:15 PM, Dirk Eddelbuettel wrote:
> On 7 December 2017 at 17:56, Tomas Kalibera wrote:
> |
> | An update on this. Writing R Extensions does not recommend to have a
> | space character in R_HOME. This means that on Windows one either should
> | have SFN enabled (which is still the common case), or install into a
> | directory that does not have a space in its name (so specifically not
> | into "Program Files"). This recommendation unfortunately needs to stay
> | for now.
> |
> | WRE recommends that Makefiles are written to be robust against space
> | characters inside R_HOME. All path names passed from a Makefile to the
> | shell should be quoted at least if they include R_HOME. Make "include"
> | directives should not be used on path names that are derived from
> | R_HOME, but one should instead use the "-f" option multiple times when
> | recursively invoking make. Maintainers of packages that use "include"
> | with R_HOME have been notified. Unfortunately, the number of packages
> | that do not quote pathnames with R_HOME in Makefiles is rather large, so
> | fixing will take some time.
> |
> | Currently, R-devel should build fine on Windows with R_HOME including
> | space, including all base and recommended packages, and tests for these
> | packages should pass even though this is not regularly tested. If you
> | find a case when this does not work, please submit a bug report.
>
> Why does the Windows installer default to using a directory with spaces?
It's a convention on Windows and I guess there may be problems with 
permissions on other directories. My hope is we can make R work reliably 
without SFN just in time before SFN become disabled by default, after 
all, quoting pathnames in Makefiles (or shell scripts for that matter) 
is a good practice anyway and avoiding "include" is not a big problem as 
very few packages are affected.

But thanks for opening this and I am happy for insights from any Windows 
experts on the issue. I would not want to violate the convention for all 
users when just few of them have SFN disabled, and as I hope this will 
be fixed on R/packages side, but maybe the installer could at least 
detect the problem (when "Program Files" or another specified target 
directory did not have a short name). Or perhaps also suggest a 
different default. Certainly R could print a warning when it starts.

Tomas
> Related (but moderately more advanced), why does R still install "everything"
> under one (versioned) directory so that uninformed users on upgrade "miss"
> all previously installed packages?
>
> Why not (with space for exposition here, imagine s/ // everywhere below)
>
>      $SOMEROOTDIR / R /
>                        R-a.b.c/          # before
>                        R-a.b.d/          # d > c, here
>                        site-library/     # with .libPaths having this preset?
>
> I don't really care as I manage to work mostly / entirely on another OS, but
> I just don't understand why we do not put two and two together. But I am
> likely unaware of some salient issues.

>
> In any event, I appreciate the thankless work of those taking care of Windoze
> (ie Tomas, Jeroen, Duncan (now ex-officio), Brian, ...)
>
> Dirk
>



[Rd] Bug: Issues on Windows with SFN disabled
Tomas Kalibera