Consistent Makevars/Makefiles for packages calling C++ libraries

[ischlo]

I have a specific problem, but it is related to a pretty general aspect of package development.
I am writing a package that uses the libosmium C++ library in the background and then provides results to R with Rcpp. Locally, I set it up with the right compilation options : the include path and library directory in the makevars of the package, it works with no errors with the default Mac compiler (clang++). However, I don't know how to set up the right makevars/Makefile in order for the package to find the necessary paths on any machine.
Is there a good documentation somewhere or process explained to develop such things ? Any recommendations and examples are much welcome. Thanks
Ivann

[jdblischak]

@ischlo

I am writing a package that uses the libosmium C++ library in the background and then provides results to R with Rcpp.

To clarify, are you vendoring libosmium (ie copying the source files into the R package) or are you accessing libosmium installed on the system?

@ischlo

However, I don't know how to set up the right makevars/Makefile in order for the package to find the necessary paths on any machine.

Since you have it working fine locally, I recommend setting up CI jobs to run it on other operating systems with usethis::use_github_actions(). Then if it does fail on another machine, hopefully the error messages can point you in the right direction.

Here are some other resources that could potentially be useful:

• Rcpp vignette Thirteen Simple Steps for Creating An R Package with an External C++ Library (this example venders a C++ library)
• Writing R Extensions section on Configure and cleanup

[ischlo]

Hello,
Thanks for your quick reply,
Currently, it is accessing libosmium installed on the machine and I would prefer it to be this way. In my case it came from homebrew. Is it recommended to copy the whole library in the package source ? especially as it's header only.
I will try using GitHub actions, thanks for the recommendation.
Ivann

[jdblischak]

@ischlo

Currently, it is accessing libosmium installed on the machine and I would prefer it to be this way.

From my perspective that is fine, but maybe others will chime in. I asked because whether or not the code is vendored within the package will affect how difficult it will be to robustly find the shared library on other platforms like Linux and Windows.

[ischlo]

Yes, but actually it might only slightly facilitate the task as libosmium depends on some non-obvious libraries itself, like protozero. Probably it adds up to a lot of files for just a few functionalities if I include it all. And then as far as I understand, the libraries are only accessed by the package and not by other potential programs on the machine ?
Since libosmium is also a CL tool, it would be ideal to just find it, or if absent, suggest to install it with a package manager. Will keep digging on this. Thanks John

[jdblischak]

@ischlo

Since libosmium is also a CL tool, it would be ideal to just find it, or if absent, suggest to install it with a package manager.

That's a viable option is the CL tool returns structured output that is easy to parse. You can check for the availability of the tool with Sys.which(). And then if it is available on the path, you can call it with system(intern = TRUE) or system2(stdout = TRUE)

[ischlo]

That's what one package (rosmium) does already, but it has limited applications. For the functionalities I work on, you need to use the library itself.