A third release of the crc32c package is now on CRAN. The package bring the Google library crc32c to R and offers cyclical checksums with parity in hardware-accelerated form on (recent enough) intel cpus as well as on arm64.
This release is one hundred percent maintenance. Brian Ripley reached
out as he already tests the (still very much unreleased)
cmake 4.0.0 release, currently at rc5. And that version is
now picky about minimum cmake version statements
in CMakeLists.txt. As we copied the upstream one here, with its setting
of the jurassic 3.1 version, our build conked out. A simple switch to
3.5..4.0, declaring a ‘from .. to’ scheme with a minimally
supported version (here 3.5, released in 2016) up to a tested version
works. No other changes, really, besides an earlier helping hand from Jeroen concerning cross-compilation
support he needed or encountered (and that happened right after the
0.0.2 release).
The NEWS entry for this (as well the initial release) follows.
Changes in version 0.0.3 (2025-03-25)
Support cross-compilation by setting CC and CXX in Makevars.in (Jeroen Ooms in #1)
Support pre-release 4.0.0 of
cmakeby moving the minimum stated version from 3.1 to 3.5 per CRAN request, also sent PR upstream
My CRANberries
service provides a comparison to the
previous release. The code is available via the GitHub repo, and of
course also from its
CRAN page and via install.packages("crc32c"). Comments
and suggestions are welcome at the GitHub repo.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.
A first follow-up to the initial announcement just days ago of the new crc32c package. The package offers cyclical checksum with parity in hardware-accelerated form on (recent enough) intel cpus as well as on arm64.
This follow-up was needed because I missed, when switching to a
default static library build, that newest compilers would
complain if -fPIC was not set. gcc-12 on my
box was happy, gcc-13 on recent Fedora as used at CRAN was
not. A second error was assuming that saying
SystemRequirements: cmake would suffice. But hold on
whippersnapper: macOS always has a surprise for you! As
described at the end of the appropriate section in Writing R
Extensions, on that OS you have to go the basement, open
four cupboards, rearrange three shelves and then you get to use it. And
then in doing so (from an added configure script) I failed
to realize Windows needed a fallback. Gee.
The NEWS entry for this (as well the initial release) follows.
Changes in version 0.0.2 (2023-05-11)
Explicitly set cmake property for position-independent code
Help macOS find its cmake binary as detailed also in WRE
Help Windows with a non-conditional Makevars.win pointing at cmake
Add more badges to README.md
Changes in version 0.0.1 (2023-05-07)
- Initial release version and CRAN upload
If you like this or other open-source work I do, you can now sponsor me at GitHub.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Happy to announce a new package: crc32c. This
arose out of a user request to add crc32c (which is related
to but differnt from crc32 without the trailing c) to my digest
package. Which I did (for now in a branch), using the software-fallback
version of crc32c from the reference implementation by
Google at their crc32c
repo.
However, the Google repo also offers hardware-accelerated versions and switches at run-time. So I pondered a little about how to offer the additional performance without placing a dependency burden on all users of digest.
Lo and behold, I think I found a solution by reusing what R offers.
First off, the crc32c package
wraps the Google repo cleanly and directly. We include all the repo code
– but not the logging or benchmarking code. This keeps external
dependencies down to just cmake. Which while still rare in
the CRAN world is at least not entirely uncommon. So now each time you
build the crc32c R
package, the upstream hardware detection is added transparently
thanks in part to cmake. We build libcrc32c.a
as a static library and include it in the R package and its own shared
library.
And we added exporting of three key functions, directly at the C
level, along with exporting one C level function of package that other
packages can call. The distinction matters. The second step of offering
a function R can call (also from other packages) is used and documented.
By means of an Imports: statement to instantiate the
package providing the functionality, the client package obtains access
to a compiled functions its R code can then call. A number of other R
packages use this.
But what is less well known is that we can do the same with C level functions. Again, it takes an imports statement but once that is done we can call ‘C to C’. Which is quite nice. I am working currently on the branch in digest which motivated this, and it can import the automagically hardware-accelerated functionality on the suitable hardware. Stay tuned for a change in digest.
I also won and lost the CRAN lottery for once: the package made it
through the ‘new package’ checks without any revisions. Only to then
immediately fail on the CRAN machines using gcc-13 as a
-fPIC was seen as missing when making the shared library.
Even though both my
CI and the r-universe builds
were all green. Ah well. So a 0.0.2 release will be coming in a day or
two.
If you like this or other open-source work I do, you can now sponsor me at GitHub.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.