Rcpp: Attributes utilize `.fixes` in NAMESPACE

[Neil-Schneider]

It would be great for Rcpp::compileAttributes() to utilize the .fixes string described in useDynLib and Registering-native-routines.

useDynLib(mypkg, .registration = TRUE, .fixes = "<prefix>")

From my view point, it seem that it should be as simple as adding the .fixes str to the return in the packageCppPrefix() function.

[eddelbuettel]

What problem are you having that this would fix? Just asking as I am aware of this, but haven't needed it myself...

[Neil-Schneider]

I was having problems with the following Notes when running devtools::check().

checking foreign function calls ... NOTE
Registration problem:
  symbol '_temppkg_rcpp_hello_world' not in namespace:
   .Call(`_temppkg_rcpp_hello_world`)
See chapter 'System and foreign language interfaces' in the 'Writing R
Extensions' manual.

checking R code for possible problems ... NOTE
rcpp_hello_world: no visible binding for global variable
  '_temppkg_rcpp_hello_world'
Undefined global functions or variables:
  _temppkg_rcpp_hello_world

Upon further inspection, those are triggered from compileAttributes() writing RcppExports.R. The .Call() function wrappers, do not include the .fixes prefix and produces the Notes above during the Check.

It makes more sense that the .fixes would only need to be added here.

[eddelbuettel]

You are the fourth or fifth person having an issue with devtools. Note that Rcpp does not use devtools, or suggest/recommend it (though of course many users may). So to me, this seems an issue with devtools and as I recall, they are aware.

I suggested to close this.

[Neil-Schneider]

I believe that my issue is reproducible without devtools. I will test this and report back as I am not 100% sure.

Test Plan:

1. Create Test with cpp code and .registeration = TRUE and .fixes = "C".
2. Run Rcpp::compileAttributes to generate RccpExport files.
3. Run R CMD INSTALL
4. Run R CMD CHECK

As I am a devtools user, do you see anything missing/wrong with this plan?

[eddelbuettel]

Well .fixes=... is not currently supported, and I would like to know which open problem would be helped or solved by adding it?

[jjallaire]

Yes, we already add the "_" prefix to all Rcpp exported symbols for just
this sort of concern (preventing conflicts). We could also support .fixes
but it seems redundant.

On Tue, Oct 10, 2017 at 5:02 PM, Neil-Schneider [e-mail]
wrote:

It would be great for Rcpp::compileAttributes() to utilize the .fixes
string described in useDynLib
https://cran.r-project.org/doc/manuals/R-exts.html#useDynLib and
Registering-native-routines
https://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines
.

useDynLib(mypkg, .registration = TRUE, .fixes = "")

From my view point, it seem that it should be as simple as adding the
.fixes str to the return in the packageCppPrefix()
https://github.com/RcppCore/Rcpp/blob/master/src/attributes.cpp#L581
function.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/RcppCore/Rcpp/issues/764, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGXx6cVgiDqVnml28HZKsN41lVToxtmks5sq9t6gaJpZM4P0kkJ
.

[Neil-Schneider]

It makes sense to say that .fixes= is not supported and I would agree that it seems some what redundant. I just finished reading #636 and #732. (Thanks for being so verbose, it really filled in some gaps.)

Quote escaping with the back-tick operator feels dirty to me, but i see the reasoning behind it. I also now see that using the .fixes= runs into the same exportPattern() issues if it start with an [alpha]. While, I personally do not use exportPattern() I understand the purpose for it.

It also sounds like you reached out about excluding Native Routines from being exported in a future version of R. Any news on that? Finally, what about using .fixes as an anti-pattern in exportPattern() (assuming a .fixes parameter exists.) and then replacing _<pkgname>_ with the .fixes= string as a prefix?

[eddelbuettel]

It also sounds like you reached out about excluding Native Routines from being exported in a future version of R. Any news on that?

I got as far as verbally raising it with an R core member. Now would be the time to cook up a patch. If you're _really_ driven we could do this together but I can' lead it.

[Neil-Schneider]

I'll attempt to start on a patch and would appreciate the help. I will likely look to expand Ripley's work to limit exportPattern with a stoplist back in 2011. Where he was limiting the "hidden" functions.

Here is commit from a mirror:
https://github.com/wch/r-source/commit/769aae3b82c1b5055e242c6967deb7658d8b7e86

Also, this has moved on from adding support for .fixes so i am going to close the issue.

[eddelbuettel]

I tend to have a copy of r-devel checked out at home so I can definitely help. Let's take this offline here, and maybe collaborate on a one-off GH repo?