R devel - Mar 2017 - Platform dependent native routine registration

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?

Thanks,
Gabor

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 | edd at debian.org

On Tue, Mar 7, 2017 at 2:45 PM, Dirk Eddelbuettel <edd at debian.org>
wrote:
[...]
>
> Could you resort to preprocessor conditioning to only compile the code
> relevant for a particular platform while hiding away the inapplicable
parts?
Yes, I do exactly that. The problem is that the R code still has

.Call(c_non_existent_function_on_this_platform, ...)

and R CMD check picks up on that.

But I just found that using string literals in .Call() works just
fine. Hopefully
this will still be allowed in the long run:

.Call("c_non_existent_function_on_this_platform", ...)

Gabor