maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/tools/mlir-shlib/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

53 lines
1.4 KiB
CMake
Raw Normal View History

[MLIR] Add support for libMLIR.so Putting this up mainly for discussion on how this should be done. I am interested in MLIR from the Julia side and we currently have a strong preference to dynamically linking against the LLVM shared library, and would like to have a MLIR shared library. This patch adds a new cmake function add_mlir_library() which accumulates a list of targets to be compiled into libMLIR.so. Note that not all libraries make sense to be compiled into libMLIR.so. In particular, we want to avoid libraries which primarily exist to support certain tools (such as mlir-opt and mlir-cpu-runner). Note that the resulting libMLIR.so depends on LLVM, but does not contain any LLVM components. As a result, it is necessary to link with libLLVM.so to avoid linkage errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken because mlir-tblgen is linked against libLLVM.so and and independent LLVM components. Previous version of this patch broke depencies on TableGen targets. This appears to be because it compiled all libraries to OBJECT libraries (probably because cmake is generating different target names). Avoiding object libraries results in correct dependencies. (updated by Stephen Neuendorffer) Differential Revision: https://reviews.llvm.org/D73130
2020-02-09 11:27:54 +08:00
# Building libmlir-cpp.so fails if LLVM_ENABLE_PIC=Off
if (NOT LLVM_ENABLE_PIC)
return()
endif()
# Building libmlir-cpp.so may not work on MSVC
if (MSVC)
return()
endif()
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
get_property(mlir_libs GLOBAL PROPERTY MLIR_STATIC_LIBS)
get_property(mlir_llvm_link_components GLOBAL PROPERTY MLIR_LLVM_LINK_COMPONENTS)
[MLIR] Add support for libMLIR.so Putting this up mainly for discussion on how this should be done. I am interested in MLIR from the Julia side and we currently have a strong preference to dynamically linking against the LLVM shared library, and would like to have a MLIR shared library. This patch adds a new cmake function add_mlir_library() which accumulates a list of targets to be compiled into libMLIR.so. Note that not all libraries make sense to be compiled into libMLIR.so. In particular, we want to avoid libraries which primarily exist to support certain tools (such as mlir-opt and mlir-cpu-runner). Note that the resulting libMLIR.so depends on LLVM, but does not contain any LLVM components. As a result, it is necessary to link with libLLVM.so to avoid linkage errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken because mlir-tblgen is linked against libLLVM.so and and independent LLVM components. Previous version of this patch broke depencies on TableGen targets. This appears to be because it compiled all libraries to OBJECT libraries (probably because cmake is generating different target names). Avoiding object libraries results in correct dependencies. (updated by Stephen Neuendorffer) Differential Revision: https://reviews.llvm.org/D73130
2020-02-09 11:27:54 +08:00
list(REMOVE_DUPLICATES mlir_libs)
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
list(REMOVE_DUPLICATES mlir_llvm_link_components)
[MLIR] Add support for libMLIR.so Putting this up mainly for discussion on how this should be done. I am interested in MLIR from the Julia side and we currently have a strong preference to dynamically linking against the LLVM shared library, and would like to have a MLIR shared library. This patch adds a new cmake function add_mlir_library() which accumulates a list of targets to be compiled into libMLIR.so. Note that not all libraries make sense to be compiled into libMLIR.so. In particular, we want to avoid libraries which primarily exist to support certain tools (such as mlir-opt and mlir-cpu-runner). Note that the resulting libMLIR.so depends on LLVM, but does not contain any LLVM components. As a result, it is necessary to link with libLLVM.so to avoid linkage errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken because mlir-tblgen is linked against libLLVM.so and and independent LLVM components. Previous version of this patch broke depencies on TableGen targets. This appears to be because it compiled all libraries to OBJECT libraries (probably because cmake is generating different target names). Avoiding object libraries results in correct dependencies. (updated by Stephen Neuendorffer) Differential Revision: https://reviews.llvm.org/D73130
2020-02-09 11:27:54 +08:00
foreach (lib ${mlir_libs})
if(XCODE)
# Xcode doesn't support object libraries, so we have to trick it into
# linking the static libraries instead.
list(APPEND _DEPS "-force_load" ${lib})
else()
list(APPEND _OBJECTS $<TARGET_OBJECTS:obj.${lib}>)
endif()
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
# libClang needs this, but it causes problems for MLIR (probably
# because we use public library dependencies within MLIR.)
# list(APPEND _DEPS $<TARGET_PROPERTY:${lib},LINK_LIBRARIES>)
[MLIR] Add support for libMLIR.so Putting this up mainly for discussion on how this should be done. I am interested in MLIR from the Julia side and we currently have a strong preference to dynamically linking against the LLVM shared library, and would like to have a MLIR shared library. This patch adds a new cmake function add_mlir_library() which accumulates a list of targets to be compiled into libMLIR.so. Note that not all libraries make sense to be compiled into libMLIR.so. In particular, we want to avoid libraries which primarily exist to support certain tools (such as mlir-opt and mlir-cpu-runner). Note that the resulting libMLIR.so depends on LLVM, but does not contain any LLVM components. As a result, it is necessary to link with libLLVM.so to avoid linkage errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken because mlir-tblgen is linked against libLLVM.so and and independent LLVM components. Previous version of this patch broke depencies on TableGen targets. This appears to be because it compiled all libraries to OBJECT libraries (probably because cmake is generating different target names). Avoiding object libraries results in correct dependencies. (updated by Stephen Neuendorffer) Differential Revision: https://reviews.llvm.org/D73130
2020-02-09 11:27:54 +08:00
endforeach ()
if(MLIR_LINK_MLIR_DYLIB)
set(INSTALL_WITH_TOOLCHAIN INSTALL_WITH_TOOLCHAIN)
endif()
if(LLVM_BUILD_LLVM_DYLIB)
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
add_mlir_library(
MLIR
[MLIR] Add support for libMLIR.so Putting this up mainly for discussion on how this should be done. I am interested in MLIR from the Julia side and we currently have a strong preference to dynamically linking against the LLVM shared library, and would like to have a MLIR shared library. This patch adds a new cmake function add_mlir_library() which accumulates a list of targets to be compiled into libMLIR.so. Note that not all libraries make sense to be compiled into libMLIR.so. In particular, we want to avoid libraries which primarily exist to support certain tools (such as mlir-opt and mlir-cpu-runner). Note that the resulting libMLIR.so depends on LLVM, but does not contain any LLVM components. As a result, it is necessary to link with libLLVM.so to avoid linkage errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken because mlir-tblgen is linked against libLLVM.so and and independent LLVM components. Previous version of this patch broke depencies on TableGen targets. This appears to be because it compiled all libraries to OBJECT libraries (probably because cmake is generating different target names). Avoiding object libraries results in correct dependencies. (updated by Stephen Neuendorffer) Differential Revision: https://reviews.llvm.org/D73130
2020-02-09 11:27:54 +08:00
SHARED
${INSTALL_WITH_TOOLCHAIN}
Revert "[MLIR] Adjust libMLIR building to more closely follow libClang" This reverts commit 4f0f436749c264c16eb226c9b9b132e07e3650a6. This seems to show some compile dependence problems, and also breaks flang.
2020-05-05 03:38:45 +08:00
mlir-shlib.cpp
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
${_OBJECTS}
LINK_LIBS
${_DEPS}
LINK_COMPONENTS
${mlir_llvm_link_components}
)
target_link_libraries(MLIR PRIVATE ${LLVM_PTHREAD_LIB})
[MLIR] Add support for libMLIR.so Putting this up mainly for discussion on how this should be done. I am interested in MLIR from the Julia side and we currently have a strong preference to dynamically linking against the LLVM shared library, and would like to have a MLIR shared library. This patch adds a new cmake function add_mlir_library() which accumulates a list of targets to be compiled into libMLIR.so. Note that not all libraries make sense to be compiled into libMLIR.so. In particular, we want to avoid libraries which primarily exist to support certain tools (such as mlir-opt and mlir-cpu-runner). Note that the resulting libMLIR.so depends on LLVM, but does not contain any LLVM components. As a result, it is necessary to link with libLLVM.so to avoid linkage errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken because mlir-tblgen is linked against libLLVM.so and and independent LLVM components. Previous version of this patch broke depencies on TableGen targets. This appears to be because it compiled all libraries to OBJECT libraries (probably because cmake is generating different target names). Avoiding object libraries results in correct dependencies. (updated by Stephen Neuendorffer) Differential Revision: https://reviews.llvm.org/D73130
2020-02-09 11:27:54 +08:00
endif()
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
#message("Libraries included in libMLIR.so: ${mlir_libs}")
#message("LLVM Components included in libMLIR.so: ${mlir_llvm_link_components}")
mlir_check_all_link_libraries(MLIR)