On 1/21/24 09:44, Ivan Krylov via R-package-devel wrote:
В Sat, 20 Jan 2024 20:28:00 -0500
Johann Gaebler <m...@jgaeb.com> пишет:

most likely there’s some error on my part in how I’ve set up cpp11,
but it also seems possible that cpp11 should have detected that that
header needs to be included and added it automatically
Upon further investigation, it's more complicated than a missing

cpp11::cpp_register() uses
tools::package_native_routine_registration_skeleton() to generate these
declarations. This function works by scanning the R code for calls to
.Call(), .C(), .Fortran(), and others and then trying to come up with
appropriate prototypes for the native functions being called. For
.Call()s, the function must output the correct type of SEXP for every
argument in the generated declaration.

This works the right way, for example, in R-4.2.2 (2022-11-10) and
today's R-devel, but was broken for a while (e.g. in R-4.3.1 and
R-4.3.2), and the fix, unfortunately, hasn't been backported (not to
R-patched either): https://bugs.r-project.org/show_bug.cgi?id=18585
Thanks, ported now to R-patched.

I can suggest three workarounds.

1. Edit src/cpp11.cpp on a separate "for-CRAN" branch and rebase it on
    top of the main branch every time you update the package.

2. Install R-devel and use it to generate the source package. Strictly
    speaking, this would go against the letter of the CRAN policy
    (builds "should be done with current R-patched or the current
    release of R"), but would at least follow its spirit (use the
    version of R where the known package-building-related bug was fixed).

3. Add a configure script that would modify src/cpp11.cpp while the
    package is being installed. This way, the only thing modifying
    generated code would be more code, which is considered
    architecturally pure by some developers.

    Lots of ways to implement it, too: you can do it in a single shell
    script (using sed or patch -- are these tools guaranteed to be
    available?), delegate to tools/configure.R (that you would also
    write yourself), or go full GNU Autoconf and generate a
    megabyte-sized ./configure from some m4 macros just to replace one

    There is definitely a lot of performance art value if you go this
    way, but extra code means extra ways for it to go wrong. For more
    style points, make it a Makevars target instead of a configure

R-package-devel@r-project.org mailing list

Reply via email to