Re: [R-pkg-devel] CRAN 'blackswan' server configuration
В Fri, 20 Jun 2025 17:32:34 -0400
Tyler пишет:
> You can see the failure logs here:
>
> https://www.stats.ox.ac.uk/pub/bdr/donttest/libdeflate.log
>
> And my configure script here :
>
> https://github.com/tylermorganwall/libdeflate/blob/main/tools/config/configure.R
>
> Note that I've excluded the possibility of whitespace being the issue
> as CC is pulling `/usr/bin/ccache` and not an empty string.
You're right, it's not about the whitespace. What I think is happening
is that 'ccache' is set up as a set of symlinks with the same names as
the compilers:
$ ln -s $(which ccache) gcc
$ ./gcc -v
Using built-in specs.
<...>
gcc version 12.2.0 (Debian 12.2.0-14+deb12u1)
This should be mostly transparent - ccache reads the name of the
symlink from argv[0] and does the right thing - except configure.R uses
normalizePath(), which expands the symlink:
$ Rscript -e 'normalizePath("./gcc")'
[1] "/usr/bin/ccache"
https://github.com/tylermorganwall/libdeflate/blob/37823652cde424bcbba6916875620985be7c8837/tools/config/configure.R#L73-L78
Since CMake runs from the same shell as configure.R and so should have
the same PATH, it should be safe to tell CMake only the name of the
compiler, without Sys.which() or normalizePath().
--
Best regards,
Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN 'blackswan' server configuration
In my experience, it is best not to set CMAKE_C_COMPILER and CMAKE_CXX_COMPILER when calling cmake. R's config can include arguments in its compiler commands, and CMake does a good job figuring things out using the CC and CXX environmental variables that R sets. It's definitely smarter than I was when I tried to do it manually. See below for the example from one of my packages. https://github.com/reedacartwright/rbedrock/blob/main/configure On Fri, Jun 20, 2025, 14:33 Tyler wrote: > Hi all, > > I have several packages (libopenexr/libimath/libdeflate) that use > CMake on the CRAN that have recently been taken down for failing to > compile on the extratest “blackswan” server. As part of the configure > script, these packages pull the compiler `CC` and `CXX` variables to > build a static library. The failure is occurring because the > “blackswan” server is apparently using ccache in some sort of > non-standard way: grepping the output of `R CMD config CC` in my > configure script to detect ccache does not work, which leads me to > believe there may be an custom alias set up on the server for invoking > a compiler cache tool. You can see the failure logs here: > > https://www.stats.ox.ac.uk/pub/bdr/donttest/libdeflate.log > > And my configure script here : > > > https://github.com/tylermorganwall/libdeflate/blob/main/tools/config/configure.R > > Note that I've excluded the possibility of whitespace being the issue > as CC is pulling `/usr/bin/ccache` and not an empty string. The only > remaining reason for the failure I can think of is a custom alias. I > have a workaround written and ready to be deployed if that’s indeed > the case, but I don’t want to attempt a fix without confirming the > root cause. > > Can someone with access to the blackswan server please provide the > Makeconf configuration file or at the very least, clarify how ccache > is invoked? > > Best regards, > Tyler Morgan-Wall > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN 'blackswan' server configuration
As a long-time user of and advocate for 'ccache', I can attest that CMake has
good behaviour on its own: just tell it to use 'ccache' if found. There may
be more one than way, on a search I see '_COMPILER_LAUNCHER' [1]. And
that is used in a simple pattern I have relied upon in the past:
# Enable compiler cache to speed up recompilation
find_program(CCACHE_FOUND ccache)
if(CCACHE_FOUND)
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)
endif()
That should do the trick.
On the other hand, I found over the years that manually trying to replicate
and outsmart systems in the R package setup is not a winner as one tends to
end up in hard-to-debug corners such as the one you find yourself in.
I do however always set 'ccache' in my own '~/.R/Makevars' and once every
thousand or two packages ('Rcpp' reverse depends let me compile a few)
something breaks because the package at hand does such local gymnastics,
So in short for your external libraries I would just try to tell CMake to
build a static library and to use 'ccache' if found.
Cheers, Dirk
[1] https://cmake.org/cmake/help/latest/prop_tgt/LANG_COMPILER_LAUNCHER.html
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
