Jeroen, sorry, I think you misunderstood: CRAN machines have the compilers, but the packages were not detecting it properly and/or were violating the CRAN policies as noted, so that's why I was saying that it would make sense to have a unified approach so that each package author doesn't have to make the same mistakes over again.
Cheers, Simon > On Nov 13, 2022, at 7:27 AM, Jeroen Ooms <jer...@berkeley.edu> wrote: > > On Sat, Nov 12, 2022 at 12:49 AM Simon Urbanek > <simon.urba...@r-project.org> wrote: >> >> this does not directly address your question, but I think it would make a >> lot of sense to standardize the process, given how many issues there were >> with packages using Rust (mainly not detecting compilers correctly, not >> supplying source code, unsolicited writing into user's directories, not >> checking binaries etc.). Doing this right is not entirely trivial which is >> presumably where the "friction" comes from. > > All we need is the rustc/cargo toolchain to be installed on the CRAN > win/mac builders (it already is on Fedora/Debian). As mentioned above > (and before in e.g. https://jeroen.github.io/erum2018), rust uses the > native C FFI, does not need any runtime library, and can be called > directly from an R package using the C interface. There is really no > need for frameworks or engines (like Rcpp/rJava/V8), this is precisely > what makes Rust so nice as an embedded language, and why it is being > adopted in many C projects such the Linux kernel, that would never > want to deal with Java/C++/JS. > >> I'm not a Rust user myself, but just based on the other languages that have >> interfaces from R I would think that Rust users could coalesce and write a >> package that does the heavy lifting and can be used by packages that contain >> Rust code as a foundation - that's what most other language interfaces do. >> (It's quite possible that some of the projects you listed would be a good >> start). I would not recommend putting that burden onto each package author >> as it screams maintenance nightmare. > > I understand the sentiment but Rust is very different from e.g. Java. > There really isn't much "heavy lifting" to do, because there are no > complex type conversions or runtime library involved. If the same > structs are used in C and Rust, the C functions can directly call Rust > functions and vice versa. Therefore it is possible for libraries to > incrementally port pieces of C code to Rust without breaking the ABI. > Just have a look at the hello world examples such as: > https://github.com/r-rust/hellorust or for a real world example: > https://cran.r-project.org/package=gifski > ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
