Re: Guiding principle for dropping LLVM versions?

On Sun, Oct 22, 2023 at 3:46 PM Xing Guo <higuoxing(at)gmail(dot)com> wrote:
> Can we also check if the clang's version is compatible with llvm's version in llvm.m4? I have multiple llvm toolchains installed on my system and I have to specify the $CLANG and $LLVM_CONFIG variables each time I build the server against a toolchain that is not present in $PATH. If one of the variables is missing, the build system will pick up a default one whose version might not be compatible with the other. E.g., If we use clang-16 and llvm-config-15, there will be issues when creating indexes for bitcodes at the end of installation.

Hmm. Problems that occur to me:

1. We need to decide if our rule is that clang must be <= llvm, or
==. I think this question has been left unanswered in the past when
it has come up. So far I think <= would be enough to avoid the error
you showed but can we find where this policy (ie especially
commitments for future releases) is written down in LLVM literature?
2. Apple's clang lies about its version (I don't know the story
behind that, but my wild guess is that someone from marketing wanted
the compiler's version numbers to align with xcode's version numbers?
they're off by 1 or something like that).

Another idea could be to produce some bitcode with clang, and then
check if a relevant LLVM tool can deal with it.