Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/cmake/modules/TableGen.cmake | ||
|---|---|---|
| 45–54 | I hope we're not running into https://cmake.org/cmake/help/latest/command/macro.html#argument-caveats here. | |
| llvm/cmake/modules/TableGen.cmake | ||
|---|---|---|
| 45–54 | You're inside a function here, so that should be fine... | |
| llvm/cmake/modules/TableGen.cmake | ||
|---|---|---|
| 45–54 | Right, this isn't a macro. Thanks for clarifying that. | |
@beanz, a configuration error caused by this in a third-party project has been reported to me:
CMake Warning (dev) at /usr/lib/llvm-16/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
Policy CMP0057 is not set: Support new IN_LIST if() operator. Run "cmake
--help-policy CMP0057" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
IN_LIST will be interpreted as an operator when the policy is set to NEW.
Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
clang_delta/CMakeLists.txt:465 (llvm_map_components_to_libnames)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at /usr/lib/llvm-16/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
if given arguments:
"engine" "IN_LIST" "link_components"The project has cmake_minimum_required(VERSION 2.8.12) and is now running afoul CMP0057:
CMake 3.3 adds support for the new IN_LIST operator.
The OLD behavior for this policy is to ignore the IN_LIST operator. The NEW behavior is to interpret the IN_LIST operator.
This policy was introduced in CMake version 3.3. CMake version 3.25.2 warns when the policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD or NEW explicitly.
This doesn't affect us internally because we have cmake_minimum_required(VERSION 3.13.4), but should we add cmake_policy(SET CMP0057 NEW) to the exported files? Perhaps in a PUSH/POP?
IMO, this is a problem for the downstream project.
We require CMake 3.13.4 for building LLVM which allows us to use CMake 3.13 features in our CMake modules. Any project using LLVM’s CMake modules _should_ have the same requirement. If we were going to do anything to address this, the approach I would take would be to make importing the LLVM CMake modules a fatal error if CMAKE_MINIMUM_REQUIRED_VERSION is less than 3.13.4.
Supporting some parts of LLVM’s CMake on older required versions is not going to be trivial, and I don’t think we should do it.
Not sure if @phosek, @smeenai, @compnerd, or @ldionne have different thoughts.
I agree, supporting older CMake versions has never been our goal, the fact that it works today is just a coincidence. I also support including an explicit version check in exported files.
I hope we're not running into https://cmake.org/cmake/help/latest/command/macro.html#argument-caveats here.