On 7 March 2017 at 14:13, Gábor Csárdi wrote: | Dear All, | | I am trying to convert a package to native routine registration, and | not sure how to | best solve the problem of C functions that are only used for a single | platform, i.e. | Windows, Linux (& Unix) or macOS. | | If I simply provide a different method table for each platform, then the .Call() | statements for the other platforms will generate R CMD check warnings, | both for the | "undefined" global functions and the registration "problems": | | checking foreign function calls ... WARNING | Registration problems: | symbol ‘c_keyring_macos_delete’ not in namespace: | .Call(c_keyring_macos_delete, utf8(keyring), utf8(service), utf8(username)) | symbol ‘c_keyring_macos_get’ not in namespace: | .Call(c_keyring_macos_get, utf8(keyring), utf8(service), utf8(username)) | | [...] | | See chapter ‘System and foreign language interfaces’ in the ‘Writing R | Extensions’ manual.checking R code for possible problems ... NOTE | b_macos_delete: no visible binding for global variable | ‘c_keyring_macos_delete’ | b_macos_get: no visible binding for global variable | ‘c_keyring_macos_get’ | | [...] | | Undefined global functions or variables: | c_keyring_macos_create c_keyring_macos_delete | c_keyring_macos_delete_keyring c_keyring_macos_get | c_keyring_macos_list c_keyring_macos_list_keyring | c_keyring_macos_lock_keyring c_keyring_macos_set | c_keyring_macos_unlock_keyring | | If possible, I would like to avoid defining dummy functions for all functions | that are not available on a certain platform, simply because I have a lot of | them. Is it possible?
Could you resort to preprocessor conditioning to only compile the code relevant for a particular platform while hiding away the inapplicable parts? Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel