(copied from #28211)

Imho, this might be too drastic. I think at least some older clang versions might not have the issue with the VERSION file, right?

Also, there might be other reasons this might still build, e.g., using a case-sensitive file system.

@matthiasdiener I encountered the version file issue when building [email protected] with clang 13, 11 and 8 (versions below 8 aren't available via brew and building llvm with Spack is not trivial).

We can add a toggle that checks whether the file system is case-sensitive, though I don't have quick access to a macOS installation with a case-sensitive file system to test it.

I also think disabling all pre-7.0.0 versions on macOS with clang is quite drastic, but I don't have a better idea right now and I think it's better than letting people run into build errors. What do you think?

@matthiasdiener I encountered the version file issue when building [email protected] with clang 13, 11 and 8 (versions below 8 aren't available via brew and building llvm with Spack is not trivial).

We can add a toggle that checks whether the file system is case-sensitive, though I don't have quick access to a macOS installation with a case-sensitive file system to test it.

I also think disabling all pre-7.0.0 versions on macOS with clang is quite drastic, but I don't have a better idea right now and I think it's better than letting people run into build errors. What do you think?

I see your point, but Imho we aren't very sure which versions of clang/apple-clang are affected. This issue didn't really pop up until 6.10.2, so I guess older clang versions might be fine? Does it depend on some libstd++ version?

Could we print a warning instead of stopping the build?

@matthiasdiener I believe LLVM's libc++ added a <version> header in [email protected] (llvm/llvm-project@082229e) as a step to comply with the C++20 standard: https://en.cppreference.com/w/cpp/header/version. This means Charm++ 6.10.2 and below won't compile on case-insensitive file systems when libc++ v7.0.0 or greater is used. I pushed an update to this PR with a suggestion, let me know what you think (it makes a few assumptions, so it's not perfect by any means).

I have also tried Spack-installing Charm 6.10.2 with GCC on my system for a while now, but I'm running into various issues. First, the Charm 6.10.2 build script can't handle compiler names with version suffixes, like gcc-11. When I symlink the compiler to remove the suffix, the build script picks up Spack's gcc but doesn't manage to infer a g++ from it, instead it tries to run [...]/g++/gcc and fails. Since I don't really need Charm 6.10.2 I stopped debugging it at this point.

I think going forward we should really prefer the cmake build with Charm whenever possible. It's great that Charm++ supports CMake now, and I think it will make building a lot more straightforward. It's a bit much to upgrade the Spack package to CMake in this PR, but if you want I can take a stab at it when I find the time. With Spack we should be able to make the package a CMakePackage, use CMake for 7.0.0 builds onward, and fall back to the manual build script for older version.