[PATCH] Document new LLVM CMake interface and emit warning when using llvm_map_components_to_libraries
brad.king at kitware.com
Wed Jul 23 10:06:21 PDT 2014
On 07/23/2014 12:50 PM, Dan Liew wrote:
> Given that now all the client of LLVM sees is a different function
> name wouldn't it make more sense for the implementation of
> llvm_map_components_to_libraries() to just call
> llvm_map_components_to_libnames()? They seem to have the same
> signature and doing that would mean that current users of LLVM using
> CMake don't have to change their own CMakeLists.txt files.
I'm not opposed to your proposal myself but here is some history:
Takumi factored llvm_map_components_to_libnames out from the original
llvm_map_components_to_libraries in r200764 to provide an interface
for the "new" behavior while preserving the "old" behavior in the
original interface. Some projects may be doing something with the
results besides passing to target_link_libraries. I think a
deprecation warning is the only way to find out about such projects
without breaking them.
> +directory (e.g. by passing ``-DLLVM_DIR:STRING=/usr/share/llvm/cmake/`` to
Use the type PATH rather than STRING so cmake-gui will use a
file-chooser dialog to edit the value interactively. Or you
can just leave off the type: ``-DLLVM_DIR=/usr/share/llvm/cmake/``
and the find_package command should set the type for you.
More information about the llvm-commits