I think this is the same group that advertised an R package template a
while back that also clearly didn't follow R-exts rules or use any of
the best practices mentioned on this mailing list.
https://github.com/stsds/Template-Rcpp
On Wed, Jan 17, 2024 at 3:24 PM Simon Urbanek
wrote:
>
> I had
I had a quick look and that package (assuming it's
https://github.com/stsds/MPCR) does not adhere to any rules from R-exts (hence
the removal from CRAN I presume) so the failure to detect cmake is the least
problem. I would strongly recommend reading the R documentation as cmake is
just the
IAN)
SET(CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE_SAVE})
endif()
> Gesendet: Mittwoch, 17. Januar 2024 um 16:52 Uhr
> Von: "Uwe Ligges"
> An: "Matthias Gondan" , "Sameh Abdulah"
>
> Cc: "R Package Development"
> Betreff:
On 17.01.2024 08:59, Matthias Gondan wrote:
For package rswipl, cmake still seems to work, but
* one has to search for it on MacOS, see the src/Makevars, as well as the
relevant sections in Writing R extensions
* Windows Defender (also on CRAN) complains about dubious exe-files when checking
On 1/17/24 08:37, Sameh Abdulah wrote:
Hi All,
We recently encountered an installation issue with our package on CRAN. We've
been depending on CMake, assuming it is readily available by default, but it
appears to be only available on the M1mac system but not on the others. Should
we
For package rswipl, cmake still seems to work, but
* one has to search for it on MacOS, see the src/Makevars, as well as the
relevant sections in Writing R extensions
* Windows Defender (also on CRAN) complains about dubious exe-files when
checking the "endianness" of the target system. That
