Export LLVM_VERSION_MAJOR CMake variable as a directory property

[bjacob]

This allows users who include llvm-project as a subrepository to access the LLVM_VERSION_MAJOR variable on par with if they were relying on an installed LLVM and FindLLVM.cmake. They just need to do something like:

  get_directory_property(LLVM_VERSION_MAJOR DIRECTORY "third_party/llvm-project/llvm" LLVM_VERSION_MAJOR)

Context: iree-org/iree#16606 -- like other projects with similar needs that I found by some googling, our work-around had been to rely on the CMake cached variable CLANG_EXECUTABLE_VERSION. Being cached, it over time inevitably ended up having a wrong value.

[bjacob]

Just tagged 3 tentative reviewers... feel free to reassign!

[llvm-beanz]

Generally the recommended guidance has been to either include LLVM as an ExternalProject or to import the CMake package. I mention this purely as a caution. I don't have any philosophical objection to fixing the issues related to including LLVM as a subdirectory, and generally speaking those issues are bugs.

I have two concrete suggestions below to make the code easier to read and more robust for users.

[llvm-beanz]

I think it would be more idiomatic in CMake to set those values as directory or global properties, which would allow them to be accessed at any directory scope above using the get_property function.

[llvm-beanz]

note: If you set these as properties instead of variables, I don't think there is any need to only set them conditionally, they can just always be set.

[bjacob]

Thanks for teaching me better CMake! Now this PR is down to 1 line with no control flow and I have verified that my downstream project is able to read the variable like this,

  get_directory_property(LLVM_VERSION_MAJOR DIRECTORY "third_party/llvm-project/llvm" LLVM_VERSION_MAJOR)

[bjacob]

Generally the recommended guidance has been to either include LLVM as an ExternalProject or to import the CMake package.

Thanks, I didn't know about https://cmake.org/cmake/help/latest/module/ExternalProject.html . TIL. FYI @ScottTodd @stellaraccident .

[ScottTodd]

Generally the recommended guidance has been to either include LLVM as an ExternalProject or to import the CMake package.

Thanks, I didn't know about https://cmake.org/cmake/help/latest/module/ExternalProject.html . TIL. FYI @ScottTodd @stellaraccident .

Neither of those are particularly attractive options when depending on many targets in the subproject (as we do with MLIR targets). If we were just using tools like lld from LLVM as black boxes and were rarely interacting with individual libraries, header files, etc. then they might work. What's sort of tricky in our (IREE's) use of LLVM/MLIR is that we use both the individual libraries in MLIR and the linking and code generation from LLVM -- and in both opinionated and general/flexible ways.

[llvm-beanz]

Neither of those are particularly attractive options when depending on many targets in the subproject (as we do with MLIR targets). If we were just using tools like lld from LLVM as black boxes and were rarely interacting with individual libraries, header files, etc. then they might work. What's sort of tricky in our (IREE's) use of LLVM/MLIR is that we use both the individual libraries in MLIR and the linking and code generation from LLVM -- and in both opinionated and general/flexible ways.

Yep. In the past the guidance has been for projects like that to nest as LLVM subprojects. I understand reasons why that is undesirable and welcome any contributions to make your preferred workflow better supported. I just wanted to make sure you were aware that the way you're doing things is historically fraught with peril.