Remove mesa18 and libosmesa #44264
Remove mesa18 and libosmesa #44264
Conversation
spackbot-app
bot
added
core
|
Hi @alalazo! I noticed that the following package(s) don't yet have maintainers:
Are you interested in adopting any of these package(s)? If so, simply add the following to the package class: maintainers("alalazo")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 osmesaThank 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. |
|
@kwryankrattiger I plan to simplify further the stack, since I think multiplexing using virtuals, when a package provides two implementation of the same virtual, is unnecessary - and just adds complexity. I'll ping you also in subsequent PRs. Let me know if I should add other reviewers too. |
|
Just quickly paged through this. I want to do a little more testing but this looks good so far. |
|
@kwryankrattiger Unfortunately this fails in packages using the virtuals, so I guess I need to fix them in this PR too. I'll try to keep the commits well separated to ease review. |
mesa18 was introduced in spack#19528 as a way to maintain the old autotools build of mesa separate from the new meson build. We could add a second build system to mesa, but since mesa18 has been deprecated for a long time, we'll just remove it. libosmesa was used to multiplex the gl provider between mesa18 and mesa, and is thus unecessary. Remove it to reduce complexity in the graphical stack.
alalazo
force-pushed
the
packages/remove-mesa-18
branch
from
b8476e2
to
50a19f9
Compare
|
@kwryankrattiger If gitlab passes, I think this one is ready to go. |
|
The |
|
Can we get this one merged, and fix
|
|
To be clear, I'm already working on fixing the packages with the |
I only ask to fix it here because we do for visit and currently the binaries we produce in CI for the paraview+osmesa package are borked. But we can do it in a follow up too if the fix is more extensive the the visit fix.
I agree that fixing any other OSMesa packages not in CI can be pushed to another PR. |
* Remove mesa18 and libosmesa mesa18 was introduced in #19528 as a way to maintain the old autotools build of mesa separate from the new meson build. We could add a second build system to mesa, but since mesa18 has been deprecated for a long time, we'll just remove it. libosmesa was used to multiplex the gl provider between mesa18 and mesa, and is thus unecessary. Remove it to reduce complexity in the graphical stack. * Remove references to mesa18 and libosmesa * vtk: rework dependency on gl and osmesa * memsurfer: rework dependency on vtk * visit: minimal fix to avoid having both osmesa and glx
refers to #44184
mesa18was introduced in #19528 as a way to maintain the old autotools build of mesa separate from the new meson build.We could add a second build system to
mesa, but sincemesa18has been deprecated for a long time, we'll just remove it.libosmesawas used to multiplex theglprovider betweenmesa18andmesa, and is thus unnecessary. Remove it to reduce complexity in the graphical stack.