Set dll exports

[MichaelChirico]

R-exts: https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Creating-shared-objects-1

Follows r-lib/xml2#473 and Rdatatable/data.table#7607.

As noted there, it's not clear this is really needed, but it does follow the practice of other packages like {Matrix}, and signals clear intent.

---

I got here looking around at r-lib repos with $(C_VISIBILITY) declarations; I would add the equivalent file to all those repos if we think it's not a waste of time :)

https://github.com/search?q=org%3Ar-lib+%2F%5B%24%5D%5B%28%5DC_VISIBILITY%2F&type=code

[lionel-]

So the presence of the .def file allows proper visibility handling (e.g. hidden by default except for explicit exports) without setting the visibility flags?

[MichaelChirico]

Per Ivan's comment, it seems the visibility flags don't WAI on Windows?

Rdatatable/data.table#7607 (comment)

I also don't have a Windows machine to test, but if you have one, examine objdump.exe on the rlang.dll, my inference is it will show many objects, whereas the intent of the code as written was to only show one.

[lionel-]

Interesting! But as I understand things, it doesn't really matter which symbols are exported in the package DLL for these reasons:

• Unlike on Linux, the symbol namespace of loaded dlls and main binary is not flat. Each DLL has an explicit import table and only resolves symbols from DLLs it directly imports. Because of this there is no risk of accidental collisions on Windows.

• A package's DLL would have to really go out of its way to try and bind to a symbol from another package that's not exported via R's C callable mechanism. So I'm not really worried about making it 100% safe from illegal imports.

So for simplicity's sake I think we can safely ignore the win.def file here, even though R supports it?

[MichaelChirico]

Yea, I think there's really not any issue with omitting the win.def file. It's more of a "doesn't hurt, and makes the .dll closer to the .so in intent" change.

I combed the r-package-devel and r-devel archives and only find two references to win.def:

• https://stat.ethz.ch/pipermail/r-devel/2016-August/072938.html
• https://stat.ethz.ch/pipermail/r-package-devel/2023q3/009350.html

I don't think I 100% understand, but it looks like the former requires win.def to prevent 'illegal' names from being exported, and the latter is about a manually-populated .def being done incorrectly.

I will try and ask on r-devel about this if I find the time :)

[lionel-]

Unless we find a good practical reason to do it, I'd lean towards not adopting this workflow. This way it's one less thing to know about, implement support for in usethis, maintain, etc. What do you think?

[MichaelChirico]

That's my own instinct as well. I'd like to understand better why other "bedrock" packages like {Matrix} do it, though. Maybe we're missing something subtle.