With Rtools 3.x pkgbuild::rtools_path() returns "c:/Rtools/usr/bin" instead of "c:/Rtools/bin"

[sjmgarnier]

It's all in the title. I'm guessing the extra "usr" was added for compatibility with Rtools 4.x, but that doesn't correspond to the organization of the Rtools 3.x folder.

[cderv]

Here is a reprex that reproduce this issue when Rtools is found from R CMD config CC

pkgbuild::has_rtools(TRUE)
#> Scanning R CMD config CC...
#> cc_path: C:/Rtools/mingw_64/bin/gcc 
#> install_path: C:/Rtools 
#> Found compatible gcc from R CMD config CC
#> [1] TRUE
pkgbuild::rtools_path()
#> [1] "C:/Rtools/usr/bin"
sessioninfo::platform_info()
#>  setting  value                       
#>  version  R version 3.6.3 (2020-02-29)
#>  os       Windows 10 x64              
#>  system   x86_64, mingw32             
#>  ui       RTerm                       
#>  language (EN)                        
#>  collate  French_France.1252          
#>  ctype    French_France.1252          
#>  tz       Europe/Paris                
#>  date     2020-06-07
packageVersion("pkgbuild")
#> [1] '1.0.8'

It was correct in previous 1.0.7 version

pkgbuild::has_rtools(TRUE)
#> Scanning R CMD config CC...
#> cc_path: C:/Rtools/mingw_64/bin/gcc 
#> install_path: C:/Rtools 
#> Found compatible gcc from R CMD config CC
#> [1] TRUE
pkgbuild::rtools_path()
#> [1] "C:/Rtools/bin"
sessioninfo::platform_info()
#>  setting  value                       
#>  version  R version 3.6.3 (2020-02-29)
#>  os       Windows 10 x64              
#>  system   x86_64, mingw32             
#>  ui       RTerm                       
#>  language (EN)                        
#>  collate  French_France.1252          
#>  ctype    French_France.1252          
#>  tz       Europe/Paris                
#>  date     2020-06-07
packageVersion("pkgbuild")
#> [1] '1.0.7'

I think the issue is if rtools is found by using cc_path then version is set to custom

pkgbuild/R/rtools-config.R

Line 23 in 609321c

rtools(install_path, "custom", valid_binpref = TRUE)

but rtools metadata for custom is now usr/bin

pkgbuild/R/rtools-metadata.R

Lines 71 to 75 in 609321c

	"custom" = list(
	version_min = "2.10.0",
	version_max = "99.99.99",
	path = "usr/bin"
	)

Changes happened in 198621e

Hope it helps.

[jimhester]

If you need a workaround the best way I think is to make sure that Rtools adds its information to the windows registry during the installation.

[sjmgarnier]

@jimhester I found a workaround that doesn't require this. I just wanted to make you guys were aware of the issue in case other package developers run into the same problem.

[cderv]

If you need a workaround the best way I think is to make sure that Rtools adds its information to the windows registry during the installation.

Even if Rtools has its information in registry or is set in the PATH, the version from scanning the config is used. The looking order in find_rtools() is

1. Scan config for Rtools using R CMD config CC. if found returns, else ...
2. Scan for Rtools in PATH looking for ls or gcc. if found returns, else ...
3. Scan the windows registry for Rtools information.

As a reprex, the three searches will return

# searched first and selected - the resulting version is set to custom
pkgbuild:::scan_config_for_rtools(TRUE)
#> Scanning R CMD config CC...
#> cc_path: C:/Rtools/mingw_64/bin/gcc 
#> install_path: C:/Rtools
#> $version
#> [1] "custom"
#> 
#> $path
#> [1] "C:/Rtools"
#> 
#> $valid_binpref
#> [1] TRUE
#> 
#> attr(,"class")
#> [1] "rtools"
# searched second and third but not used
pkgbuild:::scan_path_for_rtools(TRUE)
#> Scanning path...
#> ls: C:\Rtools\bin\ls.exe 
#> gcc_path:  
#> VERSION.txt
#> Rtools version 3.5.0.4 
#> Version: 3.5
#> $version
#> [1] "3.5"
#> 
#> $path
#> [1] "C:/Rtools"
#> 
#> attr(,"class")
#> [1] "rtools"
pkgbuild:::scan_registry_for_rtools(TRUE)
#> Scanning registry...
#> Found C:/Rtools for 3.5
#> [[1]]
#> $version
#> [1] "3.5"
#> 
#> $path
#> [1] "C:/Rtools"
#> 
#> attr(,"class")
#> [1] "rtools"

The one found first is by R CMD config CC, and its associated version is custom. For the other, it correctly associate a version.

This means that versioncustom is used to build the path for rtools binary, and we then get what describe in #96 (comment)
If it was the rtools resulting for other search scanning, it would be the correct path built.

Why not try to do like when scanning in PATH, and try to determine the rtools version from the install_path found in scan_config_for_rtools

pkgbuild/R/rtools-config.R

Lines 20 to 24 in 198621e

	install_path <- dirname(dirname(dirname(cc_path)))
	if (debug)
	cat("install_path:", install_path, "\n")
	rtools(install_path, "custom", valid_binpref = TRUE)
	}

using

version <- installed_version(install_path, debug = debug)

Is there a specific reason to always set the version to custom when rtools is found by R CMD config CC ?
This is the first one used, and it seems it will always return this custom version 🤔

I may have missed something though...

[jimhester]

Is there a specific reason to always set the version to custom when rtools is found by R CMD config CC

Yes, because the CRAN build machines use R CMD config CC so it needs to be custom for that use case.

[cderv]

I understand.

But, as R CMD config CC is tested first, it will always return the custom version then, not a specific match version from Path or registry.
Or at least, each time I tested R CMD config CC returned something, so PATH or registry where never scanned to return the matched version. I guess the order of the scanning test is also important or could it be changed ?