@chuckatkins

Why is this patch necessary? If Mesa needs the information specifically for spack, why is spack not providing it?

Why is this patch necessary? If Mesa needs the information specifically for spack, why is spack not providing it?

@trws This isn't just for spack, it just came up in spack due to mesa not being able to check if llvm was a pre-release. This was specifically a problem for llvm-amdgpu which may branch from a llvm before the official release. This type of problem will most likely be recurrent since AMD and Intel both have forks of llvm which are not required to be based on released versions of llvm.

This is currently an open patch for llvm here and the corresponding dependent change in mesa here.

Eventually patching these via spack will not be required, but doing so now will allow other issues that may arise related to the version mismatch in llvm to be handled correctly in the mean time.

Ok, my point is that this is not in LLVM yet, it's not going to be back ported, so it's only going to work in older versions in spack right? As such, it might be better to either:

1. check it in cmake, since it's part of the installed cmake config file since 2018 that should work back to llvm 7 everywhere, with or without spack
2. have spack send in the define in MESA based on the version of libllvm it is using
3. check the version from llvm-config, since the suffix is applied to that version automatically by the build as well

I don't understand how managing this patch in spack helps this process rather than complicates maintenance.