{libGL,libGLU}: use the OpenGL framework on Darwin #321800
Conversation
This reduces the reverse closure of Mesa on Darwin considerably. As a result, we can also drop the Mesa stubs package entirely, as its output on Linux is functionally identical to libglvnd. It should no longer be necessary for packages to switch between libGL and darwin.apple_sdk.frameworks.OpenGL depending on the platform. A cross‐platform libGLX alias is added for packages that specifically need it (mostly old X11 applications that barely know what a macOS is). Co-authored-by: K900 <me@0upti.me>
freeglut requires GLX; this allows more packages to work with the native macOS GLUT framework without conditionals.
Allow the macOS GLUT framework to be used automatically in many cases. Packages that specifically search for freeglut or require its additional APIs should still explicitly depend on it. Deliberately skip the Haskell package set, which is mostly automatically generated, and mupdf, which has its own fork of freeglut.
These were now broken on Darwin; most of them were unnecessary, but best practice for the remaining ones is to use `lib.getDev`.
This requires hacks to build against Apple’s OpenGL framework, and there’s no point; macOS ships with a GLU implementation already, so this package should only be used for X11 applications that explicitly require Mesa’s libGLX and want `<GL/glu.h>`.
Required on Darwin.
Required on Darwin.
The upstream code can already successfully find the system framework on macOS, and fontconfig isn’t used at all. Co-authored-by: Randy Eckenrode <randy@largeandhighquality.com>
This isn't really related to this change, but makes nixpkgs-review runs a lot nicer.
Needed for Darwin.
Drop the seemingly‐unused CoreServices dependency while we’re at it.
It wants a Mesa‐specific header for some reason, even though it works without X11.
On Darwin, libGL is the same as libGLU now, and the build system doesn’t like having the same path passed twice for whatever reason. Since libGLU always propagates libGL, just specify the former.
github-actions
bot
added
6.topic: python
6.topic: qt/kde
6.topic: ocaml
6.topic: steam
labels
|
This is seriously impressive work, everyone. Hugs all around. |
emilazy
requested review from
ulrikstrid,
K900,
NickCao,
SuperSandro2000,
ttuegel,
jbedo,
stigtsp,
zakame,
dasJ and
marcusramberg
as code owners
|
I can confirm the following regressions from
The Python failures are all downstream of By the way, I want to make clear that my intention is for Mesa to no longer be a channel blocker on Darwin after this. I don’t know how to confirm whether it is or not (if anyone does, please let me know!), but X11 on macOS is very marginal, so I don’t want it to get in the way of anyone’s work unless they specifically choose to care about it; it should not be a big deal for Mesa to be broken on Darwin. Hopefully this will make things easier on the Linux side as well. |
|
(Also, the Linux rebuilds should be totally harmless; |
|
I didn't find the time to look at this in the last days but it looks like you did a great work at thinking this through and testing it, so I hope there are minimal breakages. Good job! ❤️ |
Description of changes
A redo of #290421 (@K900 and @reckenrode’s work) that eliminates the stubs entirely. The majority of packages that support macOS at all can already handle Apple’s OpenGL framework, so we simply alias
libGLandlibGLUdepending on the platform, add a similar cross‐platformlibglutalias, alibGLXalias for the things that explicitly require X11, and play whack‐a‐mole with the relatively few things this breaks. This decimates Mesa’s reverse dependency tree on macOS and will hopefully promote the good cause of positive Linux–Darwin relations.An earlier version of this PR has been tested on
aarch64-darwinagainstmasterand confirmed to result in basically no regressions of anything that currently builds successfully on Hydra. The exceptions werexorg.xdriinfo, which is a one‐character fix but is inherently broken and useless on macOS anyway, andvolantes-cursors, which is prone to hanging so we’ll just have to see what Hydra makes of it. I am currently running anothernixpkgs-reviewcycle on amaster‐based version of this on the community builder, and will address any new failures and report the results when it finishes.@SuperSandro2000 asked on the previous PR how to know which OpenGL dependencies a package should use. This is a good question, and I’ve attempted to answer it in code comments, but here’s a more complete exposition:
Anything that uses OpenGL probably wants
libGLby default. A modern package that supports macOS should Just Work™ with this. If it has trouble finding-lGL, then you may need to pass in a compiler flag, as explained in the comment inall-packages.nix. If it wants<GL/gl.h>, that should be patched to<OpenGL/gl.h>on macOS. However, if it’s clearly an X11‐only package (e.g. explicitly uses theglx*APIs or tries to-lGLX, or depends on an X11‐only toolkit), it should depend onlibGLXinstead, and shouldn’t require any flags or patching. This will probably not apply to many new packages, as modern software will get an OpenGL context from a toolkit; it should only be relevant when packaging crusty software from the times when OS X had pinstripes and Wayland was just a town in Massachusetts. When in doubt, ping@NixOS/darwin-maintainersfor a check.Anything that also wants
glu.h/glu*functions should depend onlibGLU, unless it also needslibGLX, in which case it should usemesa_glu(which propagateslibGLX). There may be similar issues with linker paths or<GL/glu.h>instead of<OpenGL/glu.h>; using flags and patching is preferable to bringing inmesa_gluunless the software only supports X11. (This bit is ugly: Apple’s GLU should really work fine even for X11‐only software, it’s just that if the package requireslibGLXanyway then you might as well use the Mesa implementation and save having to wrangle the headers and linking.)Anything that wants GLUT should depend on
libglut, unless it uses freeglut‐specific APIs or otherwise won’t work with the GLUT framework, in which case it should depend onfreeglutif those issues can’t be patched out. (This means it will only work on X11 and might wantlibGLXtoo.)Very little should depend on
mesa,mesa_glu,libglvnd, orfreeglutexcept as noted here. The exceptions relate to various random non‐standard headers and internal APIs; when in doubt, consult an expert.Previously, it was required to have explicit conditionals to use
libGLon Linux anddarwin.apple_sdk.frameworks.OpenGLon Darwin (and similarly for GLUT). As of this pull request, this is no longer necessary, and it’s fine to clean things up to uselib{GL,GLU,glut}unconditionally. You might still need to add frameworks like Cocoa on Darwin, and conditionalize X11 dependencies on not‐Darwin, but a simple package that gets an OpenGL context from a modern cross‐platform toolkit shouldn’t need any conditionals.If the workarounds above end up being annoyingly common, separate macOS‐specific stubs packages could be created that provide things like
include/GL,lib/libGL.dylib, andlib/pkgconfig/gl.pcusing the underlying frameworks. In practice, I only had to deal with a very small number of these, as any software that supports macOS natively without X11 is extremely likely to already handle the framework format, given that it’s what you get from the OS. (One of the exceptions was a direct result of the current Nixpkgs weirdness!)In general, adding
libGLshould be all you need a substantial fraction of the time, given that GLU and GLUT are not very popular these days. If you can think of a better way to document all of this in‐tree, please do let me know, and feel free to ping me (disclaimer: no SLA) if you’re ever unsure; I’ve become much more familiar with all this than I ever wanted to be and I may as well put it to good use.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.