Hi @stephencrowell! I noticed that the following package(s) don't yet have maintainers:

• libglvnd
• libglvnd-fe
• mesa-demos
• opengl

Are you interested in adopting any of these package(s)? If so, simply add the following to the package class:

    maintainers = ['stephencrowell']

If not, could you contact the developers of this package and see if they are interested? You can quickly see who has worked on a package with spack blame:

$ spack blame libglvnd

Thank you for your help! Please don't add maintainers without their consent.

You don't have to be a Spack expert or package developer in order to be a "maintainer," it just gives us a list of users willing to review PRs or debug issues relating to this package. A package can have multiple maintainers; just add a list of GitHub handles of anyone who wants to volunteer.

Hi @stephencrowell I wanted to check in: was this ready for another review?

@scheibelp Sorry, I was out of office for the holidays. Yes, the PR is ready for review again. Thanks in advance.

Hi @stephencrowell I wanted to check in: was this ready for another review?

@scheibelp Please do yes. We're trying to get all the GL rework landed this week. Regarding the GL version information, it's really a runtime API version so I'm not sure it makes sense to specify in the provides. For example, mesa can provide 4.6 but some drivers will only provide 3.2, etc. If we really need the version info tough then we can put it in, it will just be somewhat arbitrary.

Regarding

Please let me know if any of those look wrong.

in #26301 (review) - can you respond to that?

Since that helps dependents determine whether they have a sufficiently new implementation of opengl (in particlular when requesting it via asking for a particular gl version).

For 'gl', the version is runtime dependent, not compile time dependent. There is no meaning attached to a version at this level.

Regarding the GL version information, it's really a runtime API version so I'm not sure it makes sense to specify in the provides. For example, mesa can provide 4.6 but some drivers will only provide 3.2, etc.

If the drivers are automatically selected at runtime, then it could make sense to specify the highest version that is provided. If this highest version can change between systems/installations, then that is likely something that needs to be accounted for in Spack's model.

I've looked through this more and have a couple more requests. Also based on reading through these packages I think the following are all valid dependency trees for mesa-demos:

# Provided virtuals are given in parentheses before the dependency
mesa-demos+osmesa
- (gl, osmesa) mesa+osmesa+opengl~glvnd

mesa-demos+osmesa
- (osmesa) mesa+osmesa+opengl+glvnd
    - libglvnd
- (gl) opengl~glvnd

mesa-demos+osmesa
- (osmesa) mesa+osmesa+opengl+glvnd
    - libglvnd
- (gl) libglvnd-fe
    - libglvnd
    - (libglvnd-be-*) mesa+osmesa+opengl+glvnd
        - libglvnd

mesa-demos~osmesa
- (gl) libglvnd-fe
    - libglvnd
    - (libglvnd-be-*) mesa+opengl+glvnd
        - libglvnd

mesa-demos~osmesa
- (gl) libglvnd-fe
    - libglvnd
    - (libglvnd-be-*) opengl+glvnd

mesa-demos~osmesa
- (gl) mesa+opengl~glvnd

That's not comprehensive but I'm trying to get a sense of the overall organization of things. Please let me know if any of those look wrong.

After coming up with these examples I think it would be clearer if mesa's +opengl variant were renamed to +gl.

We updated mesa-demos to no longer depend on gl without +glx or +egl. Regardless, I believe that all of these dependency trees are valid.

Would it also be possible to model this by

• Removing the libglvnd-fe package
• Having opengl+glvnd depend on libglvnd when +glvnd
• Implement gl_libs, glx_libs, etc. in mesa/opengl


? I think that might be easier to understand (if it works)

Would it also be possible to model this by

* Removing the libglvnd-fe package

* Having opengl+glvnd depend on libglvnd when +glvnd

* Implement gl_libs, glx_libs, etc. in mesa/opengl


? I think that might be easier to understand (if it works)

I don't see why it wouldn't be possible; however, I am not sure how this makes it easier to understand. While this reduces the number of packages that can provide gl, this pushes all of the complexity inside the libglvnd-fe package into opengl and mesa.

I am not sure how this makes it easier to understand. While this reduces the number of packages that can provide gl, this pushes all of the complexity inside the libglvnd-fe package into opengl and mesa.

My intent is to simplify some of the trees like:

mesa-demos+osmesa
- (osmesa) mesa+osmesa+opengl+glvnd
    - libglvnd
- (gl) libglvnd-fe
    - libglvnd
    - (libglvnd-be-*) mesa+osmesa+opengl+glvnd
        - libglvnd

into

mesa-demos+osmesa
- (osmesa, gl) mesa+osmesa+opengl+glvnd
    - libglvnd

Overall, I think the variants which switch mesa between a direct and indirect provider are somewhat complex (it took me multiple hours of reading this PR to get a sense of how these were supposed to relate - so minimally I think some explanation would be extremely useful).

In this case, my understanding is that the complexity which would need to be transferred (EDIT) from libglvnd-fe to the mesa/opengl packages is the definition of *_libs (once libglvnd-fe is removed for example, this would also eliminate the libglvnd-be-* virtuals). To me that tradeoff is worthwhile. We might be able to discuss how to enable code reuse between the packages (admittedly it's generally difficult to do this outside of defining a new Package subclass in build_systems) if that's the primary concern.

Would it also be possible to model this by

* Removing the libglvnd-fe package

* Having opengl+glvnd depend on libglvnd when +glvnd

* Implement gl_libs, glx_libs, etc. in mesa/opengl


? I think that might be easier to understand (if it works)

It is complicated but the other ways I've tried to represent it don't actually work because of dependency inversions. The basic problem that brings the complexity is that different parts of libglvnd sit at different places in the dependency hierarchy. It provides the libraries and headers needed by an application using OpenGL but it also provides the libraries and headers needed by a runtime GL implementation. Nothing inherently depends on the runtime implementation though. Just having the opengl and mesa packages depend on libglvnd breaks the external use case since a stand alone installation of a glvnd-enabled mesa or opengl driver only installs the runtime backends for glvnd with none of the headers and stub libraries needed an application. So we need to have a way to enable an externally provided opengl with a spack-provided libglvnd. The way we currently have it is the only way I've been able to see it work so that an application get's the headers and stub libraries provided libglvnd and still requires a backend implementation to be available for runtime, which will in turn also depend on libglvnd to build.

Just having the opengl and mesa packages depend on libglvnd breaks the external use case since a stand alone installation of a glvnd-enabled mesa or opengl driver only installs the runtime backends for glvnd with none of the headers and stub libraries needed an application.

One possibility is to create an analog of CudaPackage which adds a dependency on libglvnd like:

class GlPackage(Package):
  depends_on(gl)
  depends_on(libglvnd, when=^mesa+glvnd)
  depends_on(libglvnd, when=^opengl+glvnd)

  def setup_build_environment(self, env):
    ...

and then packages which would declare a depndency on gl would need to inherit this package. On one hand, this pushes some complexity to dependents of gl. On the other hand, I think this makes it easier to maintain opengl and mesa (in my opinion a lot easier). And I could consider how to make Spack support this use case more easily (for one, we are working on mechanisms for integrating externals with dependencies, which may be useful for things like this in the future).

BTW this is complex enough where if you want to discuss it in a meeting I could set one up: I'm hoping my suggestions are straightforward to implement but I may be overlooking something.

Just having the opengl and mesa packages depend on libglvnd breaks the external use case since a stand alone installation of a glvnd-enabled mesa or opengl driver only installs the runtime backends for glvnd with none of the headers and stub libraries needed an application.

One possibility is to create an analog of CudaPackage which adds a dependency on libglvnd

That would push a fair ammount more complexity onto the consuming application's package, which I'd really like to avoid. The implementation here keeps the complexity restricted to the underlying gl stack in just a hand full of packages instead of requiring every consumer of opengl to be changed. We could simplify it some to use glvnd always when on linux instead of enabling it as a variant. This should be doable, even for mesa18, since vendor binary drivers have been providing both direct and glvnd-indirect libraries with their installations for years now.

It looks like we also had a large documentation section that got left out. Would that address your concerns: adding the documentation and removing glvnd as a variant to just always use the indirect implementation?

Note that splitting libglvnd into multiple pseudo and virtual packages is a common approach and how all the primary distro package managers have been dealing with this for a few years now.

It looks like we also had a large documentation section that got left out. Would that address your concerns: adding the documentation

Documentation might help, I'd be interested to read it and get a sense of whether it makes things easier to understand. That being said IMO the overall modeling is complex and I'd like to improve it.

and removing glvnd as a variant to just always use the indirect implementation?

That would simplify things, I think that would mean

• opengl/mesa are always indirect providers (i.e. +glvnd is now what always happens)
• all packages would now require libglvnd (EDIT: all packages depending on gl would need libglvnd)

I'm not sure about the ramifications of the second constraint: would some users potentially not be able to use this on older systems (in other words, what was ~glvnd for)?

Is this PR still relevant?

This pull request has been automatically marked as stale because it has not had
any activity in the last 6 months. It will be closed if there is no further activity.
Thank you for your contributions!

This pull request was closed because it had no activity for 30 days after being marked stale.