[R-pkg-devel] Best way to build CRAN packages that include Rust source?

David Norris d@v|d @end|ng |rom prec|@|onmethod@@guru
Thu Jun 24 02:46:13 CEST 2021

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,

From: R-package-devel <r-package-devel-bounces using r-project.org> on behalf of David Norris <david using precisionmethods.guru>
Date: Monday, May 3, 2021 at 2:44 PM
To: "r-package-devel using r-project.org" <r-package-devel using 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 using r-project.org<mailto:R-package-devel using r-project.org> mailing list

	[[alternative HTML version deleted]]

More information about the R-package-devel mailing list