I see now, you're using dialog-style programs on Unix-like operating
systems. That's clever.
Note that CRAN packages are not allowed to take over the standard input
and standard output, so you might have to #ifdef that out of the code
for the R package, or maybe use R functions for terminal output instead
of standard input/output.
and everything is considered/treated as UTF-8.
Also very useful. Make sure to use enc2utf8 then.
I don't know what UCRT is
UCRT stands for "universal C runtime", a new standard C library
implementation that makes it possible to use UTF-8 as the "ANSI"
encoding on Windows. Much less important you use the "W" (wchar_t) APIs
on Windows.
I was hoping to find a tldr version of the "how to write an
extension".
Start with utils::package.skeleton or pkgKitten and fill in the blanks
until it both works and passes R CMD check --as-cran. (Start with R CMD
check without --as-cran to have a less intimidating list of things to
fix.)
What files are supposed to be in my package ? the C file
or the compiled shared libraries ?
The C file goes into src/. Also add useDynLib(YOURPACKAGENAME) to the
NAMESPACE file to avoid the need for dyn.load(potentially unknown path
to the shared library) in your R function. For best results, declare
your entry points as described in WRE 5.4.
What else ? a documentation file? is there a model to follow?
Yes, any R function you export will need to have a corresponding help
page in a man/*.Rd file. You can start with prompt() to create a
skeleton to fill. I think that both utils::package.skeleton and
pkgKitten will make you such a skeleton as part of the package if you
give them an R function to put there.
(Let's keep Cc: r-package-devel at r-project.org so that others on the
list may offer their advice too.)