Description
Currently, compiling an application with PackageCompiler.jl
breaks if you rely on Makie
integration.
Building a non-incremental sysimage fails without a very helpful error message:
⡆ [00m:18s] PackageCompiler: compiling nonincremental system image
[91416] signal (11.2): Segmentation fault: 11
in expression starting at /Users/st/.julia/packages/Colors/E2qak/src/conversions.jl:681
unknown function (ip: 0x0)
Allocations: 43500533 (Pool: 43457212; Big: 43321); GC: 61
✖ [00m:18s] PackageCompiler: compiling nonincremental system image
ERROR: failed process: Process([...]) [0]
This might be a problem with Colors.jl
, but I haven't been able to reproduce it outside of QML. For instance, the Lorenz-attractor demo in the Makie docs compiles with zero messing around.
Regardless: Building an application with an incremental sysimage is possible. The resulting application, however, fails at the @require ...
step loading the integration code:
┌ Warning: Error requiring `GLMakie` from `QML`
│ exception =
│ LoadError: ArgumentError: Package QML does not have CxxWrap in its dependencies:
│ - You may have a partially installed environment. Try `Pkg.instantiate()`
│ to ensure all packages in the environment are installed.
│ - Or, if you have QML checked out for development and have
│ added CxxWrap as a dependency but haven't updated your primary
│ environment's manifest file, try `Pkg.resolve()`.
│ - Otherwise you may need to report an issue with QML
The error itself is probably technically unrelated to the use of @require
, but I think conditionally loading t he integration code at rutime is pretty silly anyways, since I bet it breaks precompilation. I have succesfully managed to compile my application using an incremental sysimage by adding GLMakie
and Makie
as dependencies to QML
, pinned at Makie version 0.17.3
, and modifying QML
to include the integration code unconditionally, but obviously this isn't something we would want to do.
I can see in the roadmap that making sure PackageComiler works and splitting out the Makie intgration code are both on there. I think making QtMakie
a separate package would go a long way in fixing both issues, as we then aren't relying on this dodgy way of loading the integration code.
If you want, I can try my hand at making such a package. I think the best place to start is to just rip the code as is into a package that is compat
with Makie 0.17.3
, and from there I'll have a go at supporting a modern Makie version.