To follow up, I’m quite settled on (2) now, as I’ve been able to adapt the Makevars files of package ‘gifski’ to achieve a successful R-CMD-check across multiple GitHub virtual platforms including windows. For anyone interested, the Makevars & Makevars.win files are in https://github.com/dcnorris/precautionary/tree/main/src The GitHub workflow is at https://github.com/dcnorris/precautionary/blob/main/.github/workflows/R-CMD-check.yaml Kind regards, David
From: R-package-devel <r-package-devel-boun...@r-project.org> on behalf of David Norris <da...@precisionmethods.guru> Date: Monday, May 3, 2021 at 2:44 PM To: "r-package-devel@r-project.org" <r-package-devel@r-project.org> Subject: [R-pkg-devel] Best way to build CRAN packages that include Rust source? I am appreciating 2 distinct approaches currently used to compile Rust code in R packages: 1. LinkingTo: cargo, as done in https://CRAN.R-project.org/package=salso 2. A more ‘traditional’-looking approach built on Autoconf & Automake https://CRAN.R-project.org/package=gifski Is there any reason why one or the other would be preferred for a CRAN submission? Would one or the other design better facilitate Rust’s eventual elevation to ‘first-class’ status (like C++, Fortran) for compiling code in R packages? In favor of (1), it seems to me that the “Reverse linking to:” entry at https://CRAN.R-project.org/package=cargo nicely advertises packages that use Rust, which could be useful for example code, etc. In favor of (2), it seems completely idiomatic—and so potentially more conducive to achieving first-class status for Rust. [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
