mesa: re-written to new meson build system #10482
Conversation
a9d90bf to
108a54d
Compare
108a54d to
87feac7
Compare
opadron
left a comment
There was a problem hiding this comment.
LGTM once the style checks come back green.
|
I believe we've got all the pieces to this but since it's somewhat disruptive then I'll be sure that myself and @opadron are responsive to any downstream issues that crop up because of this over the next few weeks. |
|
@chuckatkins Looks like all virtual packages are checked for a default provider, and |
|
Let's just go ahead and drop the egl virtual package entirely for now since it's really more involved and out of scope. We'll need a separate pr to start dealing with the associated infrastructure and how that plays with glvnd. |
|
@alalazo @adamjstewart how strict are we about the failing codecov check? I'm not sure what to do about it since the codecov page with the details does not load for me. This is ready for merge, otherwise. |
ax3l
left a comment
There was a problem hiding this comment.
Ok, sounds good to me. Did you try the affected packages like geant4 still build and work?
|
cc @briedel in case you want to double-check the geant4 changes |
|
I went ahead and tried installing |
|
Since the changes are approved, and I was able to build geant4 without any issues. I'm going ahead with the merge. We'll keep an eye out for any issues with downstream packages. |
|
Hello. I have a nightly build of spack packages that my company uses, and last night it broke on the mesa package. I don't have a lot of time to dig into this right now, but I thought I'd at least report it. The build log is 1000+ lines long, and I don't immediately see a smoking gun. This is using gcc-8.2.0 & ninja-1.9.0 Please let me know how I can help. |
|
@odoublewen Thanks for the report. What platform is this on (centos7, sles12, etc.)? Are you building the default spec or are you using any particular variants or constraints? |
|
Just to offer another data point, I tried installing on a |
|
It is centos7, as I should have mentioned. And yes, we do specify both variants and constraints. The intersection of our Here's the full output of |
|
I'm checking now to see if I can recreate the error with a minimal spec file.... Will update later today. |
|
I confirm that I get the same build error after starting from a new spack clone with vanilla configuration, running these commands: |
|
OK, I think found the (at least proximal) cause: |
The mesa package refers to `GL/glproto.h`. On systems that don't have the OS packages installed, this leads to failures during the build [e.g. this comment in 01482](spack#10482 (comment)). This fixes it. Tested on a minimally provisioned CentOS 7.
|
@opadron @chuckatkins feel free to see @hartzell 's proposed fix in #11360 :) |
* Mesa should depend_on('glproto')
The mesa package refers to `GL/glproto.h`. On systems that don't have
the OS packages installed, this leads to failures during the build
[e.g. this comment in
01482](#10482 (comment)).
This fixes it. Tested on a minimally provisioned CentOS 7.
* Constrain glproto prereq to when +glx
* mesa: make glproto a build only dep
Also supersedes #11301