On 12/23/21 4:52 PM, Ezra Tucker wrote:
Hi Tomas and Dirk,
Thanks for your suggestions! Between the two, got it working. I didn't
know Windows didn't do rpath, I think that you're right that setting the
PATH would have helped. I haven't seen that in an R package before, so I
did what was in the Rblpapi package, which was creating a couple of
copies of the dll in question.
Well it is very exceptional that packages link to an external DLL, only
very few CRAN packages do (another example is packages linking to JAGS).
I know about these as some of them caused trouble with staged
installation and other with the switch to UCRT, they certainly make
maintaining and improving R harder. They typically won't work correctly
with encodings on Windows. The C++ interface is particularly tricky and
fragile. So, one thing is getting this to work in your package you need
another question is whether at all it should be published on CRAN, and
if that was your plan that'd be best discussed with the CRAN repository
maintainers. In some cases there is no other way thank linking to an
external DLL, but the question is always whether such package should be
on CRAN.
On a related note, in Rblpapi Makevars.win line 47 it's downloading and
extracting the compiled library from GitHub. My understanding is that
one shouldn't include pre-compiled libraries in R packages for security
reasons, at least not for submitting to CRAN. Is doing it this way a
good way around that?
No, those concerns apply and are unrelated in principle to using an
external DLL. My understanding is that this was also an exception
discussed with the CRAN repository maintainers, but I don't know the
case specifically.
Best
Tomas
Thanks again!
-Ezra
On 12/23/21 09:34, Dirk Eddelbuettel wrote:
On 23 December 2021 at 11:07, Tomas Kalibera wrote:
| You can have a look at CRAN package Rblpapi which is using an external DLL.
Yes with one big caveat: You have to make sure the library follows what is
the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
library covering the wider underlying library and offered via a wider header.
Only C linkage works across different compiler families. You just cannot use
a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++.
But you can use C linkage. So some libraries (such as the Bloomberg API used
in Rblpapi and the TileDB API used in the tiledb package (when not using a
local build) can use a library following the hourglass pattern:
- "wide" bottom layer (may be C++ or C) with the core implementation
- "narrow" C layer accessing the bottom and priving an API providing via C
which profits from C's portable foreign function interface
- "wide" layer on top via a header-only C++ file accesssing the C and
which the C++ compiler optimizes away so that the C API is used for linking
Sounds complicated, but works great.
Good detail is in a hour-long but not-too-technical talk here
https://www.youtube.com/watch?v=PVYdHDm0q6Y
and slides etc are here
https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
