Closed sjmgarnier closed 2 years ago
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
https://github.com/r-lib/pkgbuild/blob/609321c36f36482e83aae7d9d0e42de991225fae/R/rtools-config.R#L23
but rtools metadata for custom is now usr/bin
https://github.com/r-lib/pkgbuild/blob/609321c36f36482e83aae7d9d0e42de991225fae/R/rtools-metadata.R#L71-L75
Changes happened in https://github.com/r-lib/pkgbuild/commit/198621e9611f8e74a860c04a17bcb9d66e11288e
Hope it helps.
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.
@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.
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
R CMD config CC
. if found returns, else ...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 https://github.com/r-lib/pkgbuild/issues/96#issuecomment-640125683
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
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...
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.
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 ?
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.