[R-pkg-devel] Please install cmake on macOS builders
Simon, Explicitly declaring SystemRequirements: cmake appears to be insufficient to get a build on the (otherwise lovely to have) 'macOS builder', and leads to failure on (at least) 'r-oldrel-macos-x86_64'. Would it be possible to actually have cmake installed? These daus cmake is for better or worse becoming a standard, and I rely on it for one (new) package to correctly configure a library. It would be nice to be able to rely on it on macOS too. Thanks, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Please install cmake on macOS builders
> Dirk Eddelbuettel
> on Wed, 10 May 2023 07:01:37 -0500 writes:
> Simon,
> Explicitly declaring
> SystemRequirements: cmake
> appears to be insufficient to get a build on the (otherwise lovely to
have)
> 'macOS builder', and leads to failure on (at least)
'r-oldrel-macos-x86_64'.
> Would it be possible to actually have cmake installed?
> These daus cmake is for better or worse becoming a standard, and I rely
on it
> for one (new) package to correctly configure a library. It would be nice
to
> be able to rely on it on macOS too.
Somewhat 'ditto' from here {about wanting 'cmake' to become +/-
standard tool for R packages use, *not* at all related to macOS} :
The SuiteSparse C library on parts of which our Matrix package
builds extensively has also switched their setup to use cmake
instead of make ... and this was actually one reason we have not
yet updated to the latest versions of SuiteSparse for the Matrix
package.
As Matrix is formally recommended, I would even be happy if
'cmake' became a +/- required OS tool for R ...
Martin
> Thanks, Dirk
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
--
Martin Maechler
ETH Zurich and R Core team
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Please install cmake on macOS builders
Dirk, can you be more specific, please? I suspect that it may be rather an issue in your package. All build machines have the official cmake releases installed and there are many packages that use it successfully. Here is the report on the currently installed versions. If you require more recent version, let me know. high-sierra-x86_64$ /Applications/CMake.app/Contents/bin/cmake --version | head -n1 cmake version 3.17.3 big-sur-arm64$ /Applications/CMake.app/Contents/bin/cmake --version | head -n1 cmake version 3.19.4 mac-builder-arm64$ /Applications/CMake.app/Contents/bin/cmake --version | head -n1 cmake version 3.21.2 big-sur-x86_64$ /Applications/CMake.app/Contents/bin/cmake --version | head -n1 cmake version 3.26.0 Cheers, Simon > On May 11, 2023, at 12:01 AM, Dirk Eddelbuettel wrote: > > > Simon, > > Explicitly declaring > >SystemRequirements: cmake > > appears to be insufficient to get a build on the (otherwise lovely to have) > 'macOS builder', and leads to failure on (at least) 'r-oldrel-macos-x86_64'. > > Would it be possible to actually have cmake installed? > > These daus cmake is for better or worse becoming a standard, and I rely on it > for one (new) package to correctly configure a library. It would be nice to > be able to rely on it on macOS too. > > Thanks, Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Please install cmake on macOS builders
I use the following logic in my configure script to detect cmake on the MacOS builders: https://github.com/reedacartwright/rbedrock/blob/master/configure#L39-L49 I can't remember which package I borrowed this logic from. But it would be nice if "Writing R Extensions" would expand their cmake section to cover scenarios like this one. While I would love to have something like CMake be better integrated into CRAN, I've been using Meson (https://mesonbuild.com/) for a while and like it better than CMake. On Wed, May 10, 2023 at 1:36 PM Simon Urbanek wrote: > Dirk, > > can you be more specific, please? I suspect that it may be rather an issue > in your package. All build machines have the official cmake releases > installed and there are many packages that use it successfully. Here is the > report on the currently installed versions. If you require more recent > version, let me know. > > high-sierra-x86_64$ /Applications/CMake.app/Contents/bin/cmake --version | > head -n1 > cmake version 3.17.3 > > big-sur-arm64$ /Applications/CMake.app/Contents/bin/cmake --version | head > -n1 > cmake version 3.19.4 > > mac-builder-arm64$ /Applications/CMake.app/Contents/bin/cmake --version | > head -n1 > cmake version 3.21.2 > > big-sur-x86_64$ /Applications/CMake.app/Contents/bin/cmake --version | > head -n1 > cmake version 3.26.0 > > Cheers, > Simon > > > > On May 11, 2023, at 12:01 AM, Dirk Eddelbuettel wrote: > > > > > > Simon, > > > > Explicitly declaring > > > >SystemRequirements: cmake > > > > appears to be insufficient to get a build on the (otherwise lovely to > have) > > 'macOS builder', and leads to failure on (at least) > 'r-oldrel-macos-x86_64'. > > > > Would it be possible to actually have cmake installed? > > > > These daus cmake is for better or worse becoming a standard, and I rely > on it > > for one (new) package to correctly configure a library. It would be nice > to > > be able to rely on it on macOS too. > > > > Thanks, Dirk > > > > -- > > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > > __ > R-package-devel@r-project.org mailing list > > https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!ZDzGKYSqloADeChMhl8e4QHq-S3hUWkUGBtFZOu3doH2FLaAb8quWzpo_Tbdn_aWQQY8VByJNGkqqGRXVa1gFD_cRjF7$ > [[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] Please install cmake on macOS builders
> But it would be nice if "Writing R Extensions" would expand their cmake section to cover scenarios like this one. Now that I double check, I see that it is mentioned at the end of the CMake section. So I guess, the only way to improve the section would be to include a link to a complete example script that includes all the bells and whistles needed to get CMake running with R. On Wed, May 10, 2023 at 1:45 PM Reed A. Cartwright wrote: > I use the following logic in my configure script to detect cmake on the > MacOS builders: > > https://github.com/reedacartwright/rbedrock/blob/master/configure#L39-L49 > > I can't remember which package I borrowed this logic from. But it would be > nice if "Writing R Extensions" would expand their cmake section to cover > scenarios like this one. > > While I would love to have something like CMake be better integrated into > CRAN, I've been using Meson (https://mesonbuild.com/) for a while and > like it better than CMake. > > On Wed, May 10, 2023 at 1:36 PM Simon Urbanek > wrote: > >> Dirk, >> >> can you be more specific, please? I suspect that it may be rather an >> issue in your package. All build machines have the official cmake releases >> installed and there are many packages that use it successfully. Here is the >> report on the currently installed versions. If you require more recent >> version, let me know. >> >> high-sierra-x86_64$ /Applications/CMake.app/Contents/bin/cmake --version >> | head -n1 >> cmake version 3.17.3 >> >> big-sur-arm64$ /Applications/CMake.app/Contents/bin/cmake --version | >> head -n1 >> cmake version 3.19.4 >> >> mac-builder-arm64$ /Applications/CMake.app/Contents/bin/cmake --version | >> head -n1 >> cmake version 3.21.2 >> >> big-sur-x86_64$ /Applications/CMake.app/Contents/bin/cmake --version | >> head -n1 >> cmake version 3.26.0 >> >> Cheers, >> Simon >> >> >> > On May 11, 2023, at 12:01 AM, Dirk Eddelbuettel wrote: >> > >> > >> > Simon, >> > >> > Explicitly declaring >> > >> >SystemRequirements: cmake >> > >> > appears to be insufficient to get a build on the (otherwise lovely to >> have) >> > 'macOS builder', and leads to failure on (at least) >> 'r-oldrel-macos-x86_64'. >> > >> > Would it be possible to actually have cmake installed? >> > >> > These daus cmake is for better or worse becoming a standard, and I rely >> on it >> > for one (new) package to correctly configure a library. It would be >> nice to >> > be able to rely on it on macOS too. >> > >> > Thanks, Dirk >> > >> > -- >> > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> > >> >> __ >> R-package-devel@r-project.org mailing list >> >> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!ZDzGKYSqloADeChMhl8e4QHq-S3hUWkUGBtFZOu3doH2FLaAb8quWzpo_Tbdn_aWQQY8VByJNGkqqGRXVa1gFD_cRjF7$ >> > [[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] Please install cmake on macOS builders
Simon, On 11 May 2023 at 08:35, Simon Urbanek wrote: | Dirk, | | can you be more specific, please? I suspect that it may be rather an issue in your package. All build machines have the official cmake releases installed and there are many packages that use it successfully. Here is the report on the currently installed versions. If you require more recent version, let me know. | | high-sierra-x86_64$ /Applications/CMake.app/Contents/bin/cmake --version | head -n1 | cmake version 3.17.3 | | big-sur-arm64$ /Applications/CMake.app/Contents/bin/cmake --version | head -n1 | cmake version 3.19.4 | | mac-builder-arm64$ /Applications/CMake.app/Contents/bin/cmake --version | head -n1 | cmake version 3.21.2 | | big-sur-x86_64$ /Applications/CMake.app/Contents/bin/cmake --version | head -n1 | cmake version 3.26.0 edd@rob:/tmp/lib/big-sur-arm64/results/4.3/crc32c.Rcheck$ cat 00install.out * installing *source* package ‘crc32c’ ... ** using staged installation ** libs using C compiler: ‘Apple clang version 14.0.3 (clang-1403.0.22.14.1)’ using C++ compiler: ‘Apple clang version 14.0.3 (clang-1403.0.22.14.1)’ using SDK: ‘MacOSX11.3.sdk’ mkdir crc32c/build && \ cd crc32c/build && \ cmake .. && \ make all && \ cp -v libcrc32c.a .. && \ rm -rf * /bin/sh: cmake: command not found make: *** [crc32c/libcrc32c.a] Error 127 ERROR: compilation failed for package ‘crc32c’ * removing ‘/Volumes/PkgBuild/work/1683752001-f31a3e60d7ec0840/packages/big-sur-arm64/results/4.3/crc32c.Rcheck/crc32c’ edd@rob:/tmp/lib/big-sur-arm64/results/4.3/crc32c.Rcheck$ That's from the downloaded 'results.tar.bz2' you offer. Top-level URL is https://mac.r-project.org/macbuilder/results/1683752001-f31a3e60d7ec0840/ Most of my shell understanding is based on the understanding that calling something as 'cmake' should work if a 'cmake' is installed. Yet: /bin/sh: cmake: command not found seems to point more at your system than at me. I don't do any $PATH setting or resetting. Does something else get in the way? macOS has surprised me before so maybe you can offer a hint. Hth, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Please install cmake on macOS builders
On 10 May 2023 at 13:45, Reed A. Cartwright wrote: | I use the following logic in my configure script to detect cmake on the MacOS | builders: | | https://github.com/reedacartwright/rbedrock/blob/master/configure#L39-L49 Nice. That was entirely undocumented. What a dance. It should help. | I can't remember which package I borrowed this logic from. But it would be nice | if "Writing R Extensions" would expand their cmake section to cover scenarios | like this one. Yep. | While I would love to have something like CMake be better integrated into CRAN, | I've been using Meson (https://mesonbuild.com/) for a while and like it better | than CMake. "The thing about 15 standards is ..." paraphrasing xkcd. Use of cmake often comes with a library these days so your or my preference is sadly mostly irrelevant in the matter :-/ Thanks for the snippet though. I shall try that. Adding it to WRE would indeed be a good idea. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Please install cmake on macOS builders
On 10 May 2023 at 16:02, Dirk Eddelbuettel wrote: | | On 10 May 2023 at 13:45, Reed A. Cartwright wrote: | | I use the following logic in my configure script to detect cmake on the MacOS | | builders: | | | | https://github.com/reedacartwright/rbedrock/blob/master/configure#L39-L49 | | Nice. That was entirely undocumented. What a dance. It should help. It did. I had (minimal) logic in src/Makevars to make a static lib via cmake; I now moved that up into a new script configure where I used your snippet to find cmake "even if I find myself surrounded by macOS". And with that things work. So thanks for the help. We can discuss at length if providing something in a path you cannot know ex ante know comprises "providing" something -- but I guess Simon was right that his machine had cmake. Only that I didn't know where it was. Ah well. But that is unplugged now, as is a mistake I had made in the CMakeLists.txt adaptation for a static-only build. Which only gcc-13 found so all good for another upload soon. Thanks again! Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Unneeded S3 method registration
Dear R package developers My emmeans package failed preliminary checks when I submitted an update today, apparently due to a recent change in requirements on method registration. The message I got was: * checking S3 generic/method consistency ... NOTE Apparent methods for exported generics not registered: emm_basis.Gam emm_basis.MCMCglmm emm_basis.averaging emm_basis.betareg emm_basis.brmsfit emm_basis.carbayes emm_basis.clm emm_basis.clmm emm_basis.coxme emm_basis.coxph emm_basis.default emm_basis.gam emm_basis.gamlss emm_basis.gamm emm_basis.gee emm_basis.geeglm emm_basis.geese emm_basis.gls emm_basis.gnls emm_basis.hurdle emm_basis.lqm emm_basis.lqmm emm_basis.mblogit emm_basis.mcmc emm_basis.mcmc.list emm_basis.mira emm_basis.mmer emm_basis.multinom emm_basis.nlme emm_basis.nls emm_basis.polr emm_basis.qdrg emm_basis.rms emm_basis.rq emm_basis.rqs emm_basis.stanreg emm_basis.survreg emm_basis.svyolr emm_basis.zeroinfl recover_data.MCMCglmm recover_data.averaging recover_data.betareg recover_data.brmsfit recover_data.carbayes recover_data.clm recover_data.clmm recover_data.coxme recover_data.coxph recover_data.default recover_data.gam recover_data.gamlss recover_data.gamm recover_data.gee recover_data.geeglm recover_data.geese recover_data.gls recover_data.gnls recover_data.hurdle recover_data.lqm recover_data.lqmm recover_data.manova recover_data.mblogit recover_data.mcmc recover_data.mcmc.list recover_data.mira recover_data.mmer recover_data.multinom recover_data.nlme recover_data.nls recover_data.polr recover_data.qdrg recover_data.rms recover_data.rq recover_data.rqs recover_data.stanreg recover_data.survreg recover_data.svyglm recover_data.svyolr recover_data.zeroinfl See section 'Registering S3 methods' in the 'Writing R Extensions' manual. I guess my question is "why does this matter?" There are many, many functions mentioned here, but they are all methods for emm_basis and recover_data. Both generics are in the emmeans namespace, as are all these functions. The section on registering S3 methods explains: > The standard method for S3-style UseMethod dispatching might fail to locate > methods defined in a package that is imported but not attached to the search > path. To ensure that these methods are available the packages defining the > methods should ensure that the generics are imported and register the methods > using S3method directives... But clearly all those methods flagged in the messages will be found in the same namespace as the generics -- emm_basis and recover_data -- so not being able to find them is not an issue. Moreover, emm_basis() and recover_data() are not meant to be called directly by a user, or even by code in another package. They are only meant to be called within the function emmeans::ref_grid(), and the existence of those generics and methods is simply a mechanism for being able to support a lot of different model classes. Obviously, I could add a whole lot of S3method() directives to the NAMESPACE file, but it just seems wasteful to export all those methods when they are never needed outside the emmeans namespace. Am I missing something? Thanks Russ Lenth [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
