Re: Guiding principle for dropping LLVM versions?

Hi,

On October 21, 2023 7:46:17 PM PDT, 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.

It's unfortunately not that obvious to figure out what is compatible and what not. Older clang versions work, except if too old. Newer versions sometimes work. We could perhaps write a script that will find many, but not all, incompatibilities.

For the meson build I made it just use clang belonging to the llvm install - but that's very painful when building against an assert enabled llvm, clang is slower by an order of magnitude or so.

I wonder if we should change the search order to 1) CLANG, iff explicitly specified, 2) use explicitly specified or inferred llvm-config, 3) only if that didn't find clang, search path.

>wrote:
>
>> Rebased. I also noticed this woefully out of date line:
>>
>> - PGAC_PATH_PROGS(LLVM_CONFIG, llvm-config llvm-config-7
>> llvm-config-6.0 llvm-config-5.0 llvm-config-4.0 llvm-config-3.9)
>> + PGAC_PATH_PROGS(LLVM_CONFIG, llvm-config llvm-config-17
>> llvm-config-16 llvm-config-15 llvm-config-14)
>>

It's outdated, but not completely absurd - back then often no llvm-config -> llvm-config-XY was installed, but these days there pretty much always is.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.