Skip to content

Allow to refer to external libs in Mac packaging

The Mac packaging tries rather hard to make sure the package does not depend on anything outside of it (system libs being the only exception). That's a good idea in general, but in some cases, exceptions are needed.

As usual, I'm talking about RKWard in particular: RKWard is a front-end to R. R comes with a huge ecosystem of literally thousands of add-on packages that - on Windows and Mac - are distributed as compiled binaries. R for Mac, as currently offered upstream, is not "portable" in that it requires a hardcoded installation path (inside /Frameworks; and this is not only about library search paths). While R itself could be compiled to use a different installation location, all the binary add-on packages assume /Frameworks, too, and compiling all of those from source is prohibitively laborious. Note that this is concerns the runtime, only, at build time we can make do with an R installation inside CraftRoot (and we do).

Our only real option, therefore, is to interface with an "official" R for Mac installation located in /Frameworks. (And in fact, having RKWard installable separately from R has some additional nice-to-have benefits). Specifically, one of our binaries, rkward.rbackend, has to link against three R libraries expected inside /Frameworks. All the logic for that is figured out, and our current official build for Mac already works like that, but the checking inside MacBasePackager has since become more strict.

Long story short: This patch adds the option to specify a list of allowable library paths outside of CraftRoot. Full path specs (as seen by otool) need to be specified (no partial/pattern matching), in order to make sure only the intended external libs are allowed.

Inside the RKWard blueprint, we'd now specify self.externalLibs = ["@rpath/libR.dylib", "@rpath/libRblas.dylib", "@rpath/libRlapack.dylib"].

Merge request reports