Skip to content

RFC: Allow runtime configuration of XXX_jll packages. #454

Open
@colinxs

Description

@colinxs

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions