6

I am preparing an R package for submission to CRAN. R CMD check gives me the following NOTE:

Foreign function calls to a different package:
.Fortran("cinc", ... PACKAGE = "cmprsk")
.Fortran("crstm", ... PACKAGE = "cmprsk")
See the chapter 'System and Foreign language interface' of the 'Writing R Extensions manual.

How do I get rid of this NOTE? I can't find the answer from either reading the chapter or searching the web. Maybe I am missing something very simple. I submit the package before for R2.x with the same code and never have this problem. This is something new for R3.x.

user3727599
  • 61
  • 1
  • I suspect you can't, that this is something that the CRAN maintainers just don't want you to do. – Ben Bolker Jun 10 '14 at 20:39
  • If this is the case, it is really counter productive. CRAN should explicitly say so if this is their intention and propose some suggestions/solutions. – user3727599 Jun 11 '14 at 18:10

1 Answers1

8

The warning points you toward the 'System and Foreign language interface' chapter of the Writing R Extensions manual, which says specifically (in the Writing Portable Packages section):

It is not portable to call compiled code in R or other packages via .Internal, .C, .Fortran, .Call or .External, since such interfaces are subject to change without notice and will probably result in your code terminating the R process.

To (possibly) clarify: "in R or other packages" means "in the base R system or in other packages". ("terminating the R process" means that if the guts of the function you're calling change, your code will probably crash someone's R session.)

You can say what you like about the CRAN maintainers, but they're rarely wrong on technical points, and the reasons are almost always documented somewhere.

Some of your options are:

  • if you don't want to submit to CRAN, you can ignore the NOTE.
  • you could copy the Fortran (or C) code from the other package and incorporate it in your own (you might need to be careful about license, and it would certainly be polite to ask permission)
  • you could ask the maintainers of the other package to implement and export a thin R wrapper around their low-level code
Ben Bolker
  • 211,554
  • 25
  • 370
  • 453
  • Thanks for pointing out that the NOTE is about this particular issue. I would have never guessed that. Of course, the CRAN maintainers are always right. I only wish they put out a more specific message like "The following calls have portability issues." Yes, I understand the portability issue but that leaves me no alternatives or ways to address this issue. – user3727599 Jun 12 '14 at 18:09
  • Well, there are some possible solutions - 1. make a request to the maintainer of the other package to put an R wrapper around the two fortran calls or 2. take their fortran code and make a small package for my own use. Neither of these solutions are ideal. – user3727599 Jun 12 '14 at 18:44
  • 1
    how does this comment differ from my suggestions above ... ? – Ben Bolker Jun 12 '14 at 19:09
  • That note is really badly written. I'm guessing that it really means you shouldn't call other people's compiled code, but it reads like you're not supposed to call compiled code _at all_ (since the interfaces mentioned are the only ones that exist). – Hong Ooi Nov 22 '16 at 03:02
  • when you read it carefully, the clause "in R or other packages" is key - "in R" means "in the base R system" (or however one would say that properly/technically correctly) – Ben Bolker Nov 22 '16 at 03:07
  • Yeah, that's the intended meaning, but "in R" can also be taken to mean "in the R language". Something like "in the base R distribution" would be less ambiguous. – Hong Ooi Nov 22 '16 at 03:21