[R-pkg-devel] New Package Removal because Shared Library Too Large from Debugging Symbols

[Tomas Kalibera]

On 1/21/24 09:44, Ivan Krylov via R-package-devel wrote:
> В Sat, 20 Jan 2024 20:28:00 -0500
> Johann Gaebler <me using 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
> #include.
>
> 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.
Tomas
>
> 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
>     line.
>
>     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
>     script.
>