Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Not needed on recent Windows?

Abierto
  • ¿Algo no está bien?
#199 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
r
Área
build-system

Línea de trabajo

Start by tracing pkgbuild's Windows tool-detection logic and its existing checks for Rtools and build tools. Compare the behavior for tarball installations, separate MSYS2 toolchains, and custom compilers. Done means package checks no longer require an executable Rtools installation when the necessary build tools are available.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

upkeep

Hi Gabor,

a number of packages are failing their checks on my system, claiming
that I don't have tools necessary to compile a package. This includes
checkhelper. Compilation of vol2birdR fails because it chooses incorrect
HDF5 flags, for the same underlying reason.

I indeed do have such tools. The problem is that pkgbuild assumes that
one needs to have Rtools installed on Windows from the .exe installer.
But Rtools can also be installed from a tarball, with say a separate
Msys2 installation for build tools: this is documented as a valid,
normal way to install Rtools. It is used e.g. in some github actions. So
the detection is wrong. My work-around is to create an empty
c:\rtools43\usr\bin directory, but it really shouldn't be needed.

In addition to that, one even doesn't need to have Rtools to build
packages. I think that it is not good to constrain R packages to Rtools.
This is normally not needed, makes testing and development of Rtools
harder, and would make it harder to use any custom/experimental
toolchains/tools (such as e.g. Msys2). If packages really need to depend
on some specific details (and only very few should need to) of the build
system, they should rather check for specific things in the build
system, in the same spirit as say autoconfig or cmake does. See that
e.g. the sources of R itself try to be prepared for this, allowing
"custom" tools, etc.

I don't think one should ever ask whether specifically Rtools is
installed, or which version (rather than say whether a C compiler,
Fortran compiler, or whether a simple R package can be built from
source). After all, I assume this is how you do it on Unix?

The current versions of Rtools have file ".version", which you can find
relative to $(R_TOOLS_SOFT), regardless of whether Rtools has been
installed from exe or tarball, and it gives you also the exact version -
e.g. Rtools 4.3 will be updated soon and a number of packages in it as
well. But this really shouldn't be used in packages to conditionalize on.

Best
Tomas

Lenguaje dominante
R
Estrellas
77
Forks
43
Merge medio
2 d 13 h
PR fusionados (30 d)
3

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de r-lib/pkgbuild

Todos los issues de r-lib/pkgbuild

Issues similares

Más issues de R

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.