Description
Consider the following real example:
I have a binary dependency libFoo
that that can be linked in the following ways:
- against
libglew.so
+libGL.so
(hardware-accelerated, typical for a desktop environment) - against
libglewosmesa.so
+libOSMesa.so
(software rendering fallback) - against
libEGL.so
+libglewegl.so
+libOpenGL.so
(hardware-accelerated, headless)
(As you probably guessed,libglew{egl, osmesa}.so
is just GLEW linked against each graphics backend)
Downstream, there is a Foo.jl
which depends on Foo_jll
. Ideally:
(1) Users could (optionally) specify which configuration to use (e.g. with an ENV variable).
(2) If a backend fails to load, a set of fallbacks is considered.
For (1), my first thought was to extend the definition of platforms (e.g. Linux <: Platform
) to include ENV variables e.g.:
platforms = [
Linux(:x86_64, envflags=(GLBACKEND="EGL", OPTION2="A")),
Linux(:x86_64, envflags=(GLBACKEND="GL", OPTION2="A")),
Linux(:x86_64, envflags=(GLBACKEND="EGL", OPTION2="B")),
Linux(:x86_64, envflags=(GLBACKEND="GL", OPTION2="B"))
]
This could correspond to ENV variables like "FOO_JLL_GLBACKEND" that would be exposed in the build script and that could be set by the user. Similarly, this would generate wrapper files like x86_64-linux-gnu-EGL-A.jl
.
Another option that @giordano and I discussed was to create a *_jll
package for each configuration. Following the above example, we would have:
GLEW_GL_jll
,GLEW_EGL_jll
,GLEW_OSMesa_jll
Foo_GL_jll
,Foo_EGL_jll
,Foo_OSMesa_jll
It is unclear how one would actually choose amongst these at runtime. As @giordano pointed out, this relates to the discussion in JuliaLang/Pkg.jl#1285. My other concern is that this would lead to a fair bit of code duplication and a plethora of *_jll
packages.
As for (2), that seems a bit more difficult and perhaps not as necessary, but may constrain the design of (1) so I included it here anyways.