Avoid object libraries in the VS IDE #93519
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I applied the patch locally and tried it out, and I think this is an improvement for folks generating VS solutions. |
|
@llvm/pr-subscribers-clang @llvm/pr-subscribers-mlir-gpu Author: Michael Kruse (Meinersbur) ChangesAs discussed in #89743, when using the Visual Studio solution generators, object library projects are displayed as a collection of non-editable *.obj files. To look for the corresponding source files, one has to browse (or search) to the library's obj.libname project. This patch tries to avoid this as much as possible. For Clang, there is already an exception for XCode. We handle MSVC_IDE the same way. For MLIR, this is more complicated. There are explicit references to the obj.libname target that only work when there is an object library. This patch cleans up the reasons for why an object library is needed:
This seem to not have worked with XCode because of the explicit references to obj.libname. I don't have access to XCode, but I tried to preserve the current working. IMHO there should be a common mechanism to build aggregate libraries for all LLVM projects instead of the 4 that we have now. As far as I can see, this means for LLVM there are the following changes on whether object libraries are created:
Full diff: https://github.com/llvm/llvm-project/pull/93519.diff 7 Files Affected:
diff --git a/clang/cmake/modules/AddClang.cmake b/clang/cmake/modules/AddClang.cmake
index a5ef639187d9d..9d09be1936847 100644
--- a/clang/cmake/modules/AddClang.cmake
+++ b/clang/cmake/modules/AddClang.cmake
@@ -96,8 +96,12 @@ macro(add_clang_library name)
else()
set(LIBTYPE STATIC)
endif()
- if(NOT XCODE)
+ if(NOT XCODE AND NOT MSVC_IDE)
# The Xcode generator doesn't handle object libraries correctly.
+ # The Visual Studio CMake generator does handle object libraries
+ # correctly, but it is preferable to list the libraries with their
+ # source files (instead of the object files and the source files in
+ # a separate target in the "Object Libraries" folder)
list(APPEND LIBTYPE OBJECT)
endif()
set_property(GLOBAL APPEND PROPERTY CLANG_STATIC_LIBS ${name})
diff --git a/clang/lib/Support/CMakeLists.txt b/clang/lib/Support/CMakeLists.txt
index 8ea5620052ed8..de06271e914ae 100644
--- a/clang/lib/Support/CMakeLists.txt
+++ b/clang/lib/Support/CMakeLists.txt
@@ -15,7 +15,7 @@ set(clangSupport_sources
add_clang_library(clangSupport ${clangSupport_sources})
-if (NOT XCODE)
+if (TARGET obj.clangSupport)
add_library(clangSupport_tablegen ALIAS obj.clangSupport)
elseif (NOT LLVM_LINK_LLVM_DYLIB)
add_library(clangSupport_tablegen ALIAS clangSupport)
diff --git a/flang/cmake/modules/AddFlang.cmake b/flang/cmake/modules/AddFlang.cmake
index 3a5119b83831f..aeb4d862cf780 100644
--- a/flang/cmake/modules/AddFlang.cmake
+++ b/flang/cmake/modules/AddFlang.cmake
@@ -51,19 +51,28 @@ function(add_flang_library name)
endif()
- if (ARG_SHARED)
+ if(ARG_SHARED AND ARG_STATIC)
+ set(LIBTYPE SHARED STATIC)
+ elseif(ARG_SHARED)
set(LIBTYPE SHARED)
else()
# llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
# so we need to handle it here.
- if (BUILD_SHARED_LIBS AND NOT ARG_STATIC)
- set(LIBTYPE SHARED OBJECT)
+ if(BUILD_SHARED_LIBS)
+ set(LIBTYPE SHARED)
else()
- set(LIBTYPE STATIC OBJECT)
+ set(LIBTYPE STATIC)
endif()
- set_property(GLOBAL APPEND PROPERTY FLANG_STATIC_LIBS ${name})
+ if(NOT XCODE AND NOT MSVC_IDE)
+ # The Xcode generator doesn't handle object libraries correctly.
+ # The Visual Studio CMake generator does handle object libraries
+ # correctly, but it is preferable to list the libraries with their
+ # source files (instead of the object files and the source files in
+ # a separate target in the "Object Libraries" folder)
+ list(APPEND LIBTYPE OBJECT)
+ endif()
+ set_property(GLOBAL APPEND PROPERTY CLANG_STATIC_LIBS ${name})
endif()
-
llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
clang_target_link_libraries(${name} PRIVATE ${ARG_CLANG_LIBS})
diff --git a/mlir/cmake/modules/AddMLIR.cmake b/mlir/cmake/modules/AddMLIR.cmake
index a685277209598..a3324705c525c 100644
--- a/mlir/cmake/modules/AddMLIR.cmake
+++ b/mlir/cmake/modules/AddMLIR.cmake
@@ -306,26 +306,23 @@ endfunction()
# Don't include this library in libMLIR.so. This option should be used
# for test libraries, executable-specific libraries, or rarely used libraries
# with large dependencies.
+# OBJECT
+# The library's object library is referenced using "obj.${name}". For this to
+# work reliably, this flag ensures that the OBJECT library exists.
# ENABLE_AGGREGATION
-# Forces generation of an OBJECT library, exports additional metadata,
+# Exports additional metadata,
# and installs additional object files needed to include this as part of an
# aggregate shared library.
# TODO: Make this the default for all MLIR libraries once all libraries
# are compatible with building an object library.
function(add_mlir_library name)
cmake_parse_arguments(ARG
- "SHARED;INSTALL_WITH_TOOLCHAIN;EXCLUDE_FROM_LIBMLIR;DISABLE_INSTALL;ENABLE_AGGREGATION"
+ "SHARED;INSTALL_WITH_TOOLCHAIN;EXCLUDE_FROM_LIBMLIR;DISABLE_INSTALL;ENABLE_AGGREGATION;OBJECT"
""
"ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS"
${ARGN})
_set_mlir_additional_headers_as_srcs(${ARG_ADDITIONAL_HEADERS})
- # Is an object library needed.
- set(NEEDS_OBJECT_LIB OFF)
- if(ARG_ENABLE_AGGREGATION)
- set(NEEDS_OBJECT_LIB ON)
- endif()
-
# Determine type of library.
if(ARG_SHARED)
set(LIBTYPE SHARED)
@@ -337,18 +334,39 @@ function(add_mlir_library name)
else()
set(LIBTYPE STATIC)
endif()
- # Test libraries and such shouldn't be include in libMLIR.so
- if(NOT ARG_EXCLUDE_FROM_LIBMLIR)
- set(NEEDS_OBJECT_LIB ON)
- set_property(GLOBAL APPEND PROPERTY MLIR_STATIC_LIBS ${name})
- set_property(GLOBAL APPEND PROPERTY MLIR_LLVM_LINK_COMPONENTS ${ARG_LINK_COMPONENTS})
- set_property(GLOBAL APPEND PROPERTY MLIR_LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS})
- endif()
endif()
- if(NEEDS_OBJECT_LIB AND NOT XCODE)
- # The Xcode generator doesn't handle object libraries correctly.
- # We special case xcode when building aggregates.
+ # Is an object library needed...?
+ # Note that the XCode generator doesn't handle object libraries correctly and
+ # usability is degraded in the Visual Studio solution generators.
+ # llvm_add_library may also itself decide to create an object library.
+ set(NEEDS_OBJECT_LIB OFF)
+ if(ARG_OBJECT)
+ # Yes, because the target "obj.${name}" is referenced.
+ set(NEEDS_OBJECT_LIB ON)
+ endif ()
+ if(LLVM_BUILD_LLVM_DYLIB AND NOT ARG_EXCLUDE_FROM_LIBMLIR AND NOT XCODE)
+ # Yes, because in addition to the shared library, the object files are
+ # needed for linking into libMLIR.so (see mlir/tools/mlir-shlib/CMakeLists.txt).
+ # For XCode, -force_load is used instead.
+ # Windows is not supported (LLVM_BUILD_LLVM_DYLIB=ON will cause an error).
+ set(NEEDS_OBJECT_LIB ON)
+ set_property(GLOBAL APPEND PROPERTY MLIR_STATIC_LIBS ${name})
+ set_property(GLOBAL APPEND PROPERTY MLIR_LLVM_LINK_COMPONENTS ${ARG_LINK_COMPONENTS})
+ set_property(GLOBAL APPEND PROPERTY MLIR_LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS})
+ endif ()
+ if(ARG_ENABLE_AGGREGATION AND NOT XCODE)
+ # Yes, because this library is added to an aggergate library such as
+ # libMLIR-C.so which is links together all the object files.
+ # For XCode, -force_load is used instead.
+ set(NEEDS_OBJECT_LIB ON)
+ endif()
+ if (NOT ARG_SHARED AND NOT ARG_EXCLUDE_FROM_LIBMLIR AND NOT XCODE AND NOT MSVC_IDE)
+ # Yes, but only for legacy reasons. Also avoid object libraries for
+ # Visual Studio solutions.
+ set(NEEDS_OBJECT_LIB ON)
+ endif()
+ if(NEEDS_OBJECT_LIB)
list(APPEND LIBTYPE OBJECT)
endif()
@@ -380,9 +398,12 @@ function(add_mlir_library name)
# XCode has limited support for object libraries. Instead, add dep flags
# that force the entire library to be embedded.
list(APPEND AGGREGATE_DEPS "-force_load" "${name}")
- else()
+ elseif(TARGET obj.${name})
+ # FIXME: *.obj can also be added via target_link_libraries since CMake 3.12.
list(APPEND AGGREGATE_OBJECTS "$<TARGET_OBJECTS:obj.${name}>")
list(APPEND AGGREGATE_OBJECT_LIB "obj.${name}")
+ else()
+ message(SEND_ERROR "Aggregate library not supported on this platform")
endif()
# For each declared dependency, transform it into a generator expression
@@ -402,7 +423,7 @@ function(add_mlir_library name)
# In order for out-of-tree projects to build aggregates of this library,
# we need to install the OBJECT library.
- if(MLIR_INSTALL_AGGREGATE_OBJECTS AND NOT ARG_DISABLE_INSTALL)
+ if(TARGET "obj.${name}" AND MLIR_INSTALL_AGGREGATE_OBJECTS AND NOT ARG_DISABLE_INSTALL)
add_mlir_library_install(obj.${name})
endif()
endif()
@@ -615,6 +636,7 @@ endfunction()
function(add_mlir_public_c_api_library name)
add_mlir_library(${name}
${ARGN}
+ OBJECT
EXCLUDE_FROM_LIBMLIR
ENABLE_AGGREGATION
ADDITIONAL_HEADER_DIRS
diff --git a/mlir/lib/Dialect/GPU/CMakeLists.txt b/mlir/lib/Dialect/GPU/CMakeLists.txt
index 61ab298ebfb98..8c64c2098b315 100644
--- a/mlir/lib/Dialect/GPU/CMakeLists.txt
+++ b/mlir/lib/Dialect/GPU/CMakeLists.txt
@@ -57,6 +57,8 @@ add_mlir_dialect_library(MLIRGPUTransforms
Transforms/SPIRVAttachTarget.cpp
Transforms/SubgroupReduceLowering.cpp
Transforms/Utils.cpp
+
+ OBJECT
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Dialect/GPU
diff --git a/mlir/lib/Target/LLVM/CMakeLists.txt b/mlir/lib/Target/LLVM/CMakeLists.txt
index 5a3fa160850b4..1c709e18cbfda 100644
--- a/mlir/lib/Target/LLVM/CMakeLists.txt
+++ b/mlir/lib/Target/LLVM/CMakeLists.txt
@@ -32,6 +32,8 @@ endif()
add_mlir_dialect_library(MLIRNVVMTarget
NVVM/Target.cpp
+ OBJECT
+
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Dialect/LLVMIR
@@ -109,6 +111,8 @@ endif()
add_mlir_dialect_library(MLIRROCDLTarget
ROCDL/Target.cpp
+ OBJECT
+
LINK_COMPONENTS
MCParser
${AMDGPU_LIBS}
diff --git a/mlir/tools/mlir-shlib/CMakeLists.txt b/mlir/tools/mlir-shlib/CMakeLists.txt
index 32fe833cee4ea..a33c70c5807be 100644
--- a/mlir/tools/mlir-shlib/CMakeLists.txt
+++ b/mlir/tools/mlir-shlib/CMakeLists.txt
@@ -34,6 +34,7 @@ if(LLVM_BUILD_LLVM_DYLIB)
add_mlir_library(
MLIR
SHARED
+ EXCLUDE_FROM_LIBMLIR
${INSTALL_WITH_TOOLCHAIN}
mlir-shlib.cpp
${_OBJECTS}
|
|
@llvm/pr-subscribers-mlir-llvm Author: Michael Kruse (Meinersbur) ChangesAs discussed in #89743, when using the Visual Studio solution generators, object library projects are displayed as a collection of non-editable *.obj files. To look for the corresponding source files, one has to browse (or search) to the library's obj.libname project. This patch tries to avoid this as much as possible. For Clang, there is already an exception for XCode. We handle MSVC_IDE the same way. For MLIR, this is more complicated. There are explicit references to the obj.libname target that only work when there is an object library. This patch cleans up the reasons for why an object library is needed:
This seem to not have worked with XCode because of the explicit references to obj.libname. I don't have access to XCode, but I tried to preserve the current working. IMHO there should be a common mechanism to build aggregate libraries for all LLVM projects instead of the 4 that we have now. As far as I can see, this means for LLVM there are the following changes on whether object libraries are created:
Full diff: https://github.com/llvm/llvm-project/pull/93519.diff 7 Files Affected:
diff --git a/clang/cmake/modules/AddClang.cmake b/clang/cmake/modules/AddClang.cmake
index a5ef639187d9d..9d09be1936847 100644
--- a/clang/cmake/modules/AddClang.cmake
+++ b/clang/cmake/modules/AddClang.cmake
@@ -96,8 +96,12 @@ macro(add_clang_library name)
else()
set(LIBTYPE STATIC)
endif()
- if(NOT XCODE)
+ if(NOT XCODE AND NOT MSVC_IDE)
# The Xcode generator doesn't handle object libraries correctly.
+ # The Visual Studio CMake generator does handle object libraries
+ # correctly, but it is preferable to list the libraries with their
+ # source files (instead of the object files and the source files in
+ # a separate target in the "Object Libraries" folder)
list(APPEND LIBTYPE OBJECT)
endif()
set_property(GLOBAL APPEND PROPERTY CLANG_STATIC_LIBS ${name})
diff --git a/clang/lib/Support/CMakeLists.txt b/clang/lib/Support/CMakeLists.txt
index 8ea5620052ed8..de06271e914ae 100644
--- a/clang/lib/Support/CMakeLists.txt
+++ b/clang/lib/Support/CMakeLists.txt
@@ -15,7 +15,7 @@ set(clangSupport_sources
add_clang_library(clangSupport ${clangSupport_sources})
-if (NOT XCODE)
+if (TARGET obj.clangSupport)
add_library(clangSupport_tablegen ALIAS obj.clangSupport)
elseif (NOT LLVM_LINK_LLVM_DYLIB)
add_library(clangSupport_tablegen ALIAS clangSupport)
diff --git a/flang/cmake/modules/AddFlang.cmake b/flang/cmake/modules/AddFlang.cmake
index 3a5119b83831f..aeb4d862cf780 100644
--- a/flang/cmake/modules/AddFlang.cmake
+++ b/flang/cmake/modules/AddFlang.cmake
@@ -51,19 +51,28 @@ function(add_flang_library name)
endif()
- if (ARG_SHARED)
+ if(ARG_SHARED AND ARG_STATIC)
+ set(LIBTYPE SHARED STATIC)
+ elseif(ARG_SHARED)
set(LIBTYPE SHARED)
else()
# llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
# so we need to handle it here.
- if (BUILD_SHARED_LIBS AND NOT ARG_STATIC)
- set(LIBTYPE SHARED OBJECT)
+ if(BUILD_SHARED_LIBS)
+ set(LIBTYPE SHARED)
else()
- set(LIBTYPE STATIC OBJECT)
+ set(LIBTYPE STATIC)
endif()
- set_property(GLOBAL APPEND PROPERTY FLANG_STATIC_LIBS ${name})
+ if(NOT XCODE AND NOT MSVC_IDE)
+ # The Xcode generator doesn't handle object libraries correctly.
+ # The Visual Studio CMake generator does handle object libraries
+ # correctly, but it is preferable to list the libraries with their
+ # source files (instead of the object files and the source files in
+ # a separate target in the "Object Libraries" folder)
+ list(APPEND LIBTYPE OBJECT)
+ endif()
+ set_property(GLOBAL APPEND PROPERTY CLANG_STATIC_LIBS ${name})
endif()
-
llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
clang_target_link_libraries(${name} PRIVATE ${ARG_CLANG_LIBS})
diff --git a/mlir/cmake/modules/AddMLIR.cmake b/mlir/cmake/modules/AddMLIR.cmake
index a685277209598..a3324705c525c 100644
--- a/mlir/cmake/modules/AddMLIR.cmake
+++ b/mlir/cmake/modules/AddMLIR.cmake
@@ -306,26 +306,23 @@ endfunction()
# Don't include this library in libMLIR.so. This option should be used
# for test libraries, executable-specific libraries, or rarely used libraries
# with large dependencies.
+# OBJECT
+# The library's object library is referenced using "obj.${name}". For this to
+# work reliably, this flag ensures that the OBJECT library exists.
# ENABLE_AGGREGATION
-# Forces generation of an OBJECT library, exports additional metadata,
+# Exports additional metadata,
# and installs additional object files needed to include this as part of an
# aggregate shared library.
# TODO: Make this the default for all MLIR libraries once all libraries
# are compatible with building an object library.
function(add_mlir_library name)
cmake_parse_arguments(ARG
- "SHARED;INSTALL_WITH_TOOLCHAIN;EXCLUDE_FROM_LIBMLIR;DISABLE_INSTALL;ENABLE_AGGREGATION"
+ "SHARED;INSTALL_WITH_TOOLCHAIN;EXCLUDE_FROM_LIBMLIR;DISABLE_INSTALL;ENABLE_AGGREGATION;OBJECT"
""
"ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS"
${ARGN})
_set_mlir_additional_headers_as_srcs(${ARG_ADDITIONAL_HEADERS})
- # Is an object library needed.
- set(NEEDS_OBJECT_LIB OFF)
- if(ARG_ENABLE_AGGREGATION)
- set(NEEDS_OBJECT_LIB ON)
- endif()
-
# Determine type of library.
if(ARG_SHARED)
set(LIBTYPE SHARED)
@@ -337,18 +334,39 @@ function(add_mlir_library name)
else()
set(LIBTYPE STATIC)
endif()
- # Test libraries and such shouldn't be include in libMLIR.so
- if(NOT ARG_EXCLUDE_FROM_LIBMLIR)
- set(NEEDS_OBJECT_LIB ON)
- set_property(GLOBAL APPEND PROPERTY MLIR_STATIC_LIBS ${name})
- set_property(GLOBAL APPEND PROPERTY MLIR_LLVM_LINK_COMPONENTS ${ARG_LINK_COMPONENTS})
- set_property(GLOBAL APPEND PROPERTY MLIR_LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS})
- endif()
endif()
- if(NEEDS_OBJECT_LIB AND NOT XCODE)
- # The Xcode generator doesn't handle object libraries correctly.
- # We special case xcode when building aggregates.
+ # Is an object library needed...?
+ # Note that the XCode generator doesn't handle object libraries correctly and
+ # usability is degraded in the Visual Studio solution generators.
+ # llvm_add_library may also itself decide to create an object library.
+ set(NEEDS_OBJECT_LIB OFF)
+ if(ARG_OBJECT)
+ # Yes, because the target "obj.${name}" is referenced.
+ set(NEEDS_OBJECT_LIB ON)
+ endif ()
+ if(LLVM_BUILD_LLVM_DYLIB AND NOT ARG_EXCLUDE_FROM_LIBMLIR AND NOT XCODE)
+ # Yes, because in addition to the shared library, the object files are
+ # needed for linking into libMLIR.so (see mlir/tools/mlir-shlib/CMakeLists.txt).
+ # For XCode, -force_load is used instead.
+ # Windows is not supported (LLVM_BUILD_LLVM_DYLIB=ON will cause an error).
+ set(NEEDS_OBJECT_LIB ON)
+ set_property(GLOBAL APPEND PROPERTY MLIR_STATIC_LIBS ${name})
+ set_property(GLOBAL APPEND PROPERTY MLIR_LLVM_LINK_COMPONENTS ${ARG_LINK_COMPONENTS})
+ set_property(GLOBAL APPEND PROPERTY MLIR_LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS})
+ endif ()
+ if(ARG_ENABLE_AGGREGATION AND NOT XCODE)
+ # Yes, because this library is added to an aggergate library such as
+ # libMLIR-C.so which is links together all the object files.
+ # For XCode, -force_load is used instead.
+ set(NEEDS_OBJECT_LIB ON)
+ endif()
+ if (NOT ARG_SHARED AND NOT ARG_EXCLUDE_FROM_LIBMLIR AND NOT XCODE AND NOT MSVC_IDE)
+ # Yes, but only for legacy reasons. Also avoid object libraries for
+ # Visual Studio solutions.
+ set(NEEDS_OBJECT_LIB ON)
+ endif()
+ if(NEEDS_OBJECT_LIB)
list(APPEND LIBTYPE OBJECT)
endif()
@@ -380,9 +398,12 @@ function(add_mlir_library name)
# XCode has limited support for object libraries. Instead, add dep flags
# that force the entire library to be embedded.
list(APPEND AGGREGATE_DEPS "-force_load" "${name}")
- else()
+ elseif(TARGET obj.${name})
+ # FIXME: *.obj can also be added via target_link_libraries since CMake 3.12.
list(APPEND AGGREGATE_OBJECTS "$<TARGET_OBJECTS:obj.${name}>")
list(APPEND AGGREGATE_OBJECT_LIB "obj.${name}")
+ else()
+ message(SEND_ERROR "Aggregate library not supported on this platform")
endif()
# For each declared dependency, transform it into a generator expression
@@ -402,7 +423,7 @@ function(add_mlir_library name)
# In order for out-of-tree projects to build aggregates of this library,
# we need to install the OBJECT library.
- if(MLIR_INSTALL_AGGREGATE_OBJECTS AND NOT ARG_DISABLE_INSTALL)
+ if(TARGET "obj.${name}" AND MLIR_INSTALL_AGGREGATE_OBJECTS AND NOT ARG_DISABLE_INSTALL)
add_mlir_library_install(obj.${name})
endif()
endif()
@@ -615,6 +636,7 @@ endfunction()
function(add_mlir_public_c_api_library name)
add_mlir_library(${name}
${ARGN}
+ OBJECT
EXCLUDE_FROM_LIBMLIR
ENABLE_AGGREGATION
ADDITIONAL_HEADER_DIRS
diff --git a/mlir/lib/Dialect/GPU/CMakeLists.txt b/mlir/lib/Dialect/GPU/CMakeLists.txt
index 61ab298ebfb98..8c64c2098b315 100644
--- a/mlir/lib/Dialect/GPU/CMakeLists.txt
+++ b/mlir/lib/Dialect/GPU/CMakeLists.txt
@@ -57,6 +57,8 @@ add_mlir_dialect_library(MLIRGPUTransforms
Transforms/SPIRVAttachTarget.cpp
Transforms/SubgroupReduceLowering.cpp
Transforms/Utils.cpp
+
+ OBJECT
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Dialect/GPU
diff --git a/mlir/lib/Target/LLVM/CMakeLists.txt b/mlir/lib/Target/LLVM/CMakeLists.txt
index 5a3fa160850b4..1c709e18cbfda 100644
--- a/mlir/lib/Target/LLVM/CMakeLists.txt
+++ b/mlir/lib/Target/LLVM/CMakeLists.txt
@@ -32,6 +32,8 @@ endif()
add_mlir_dialect_library(MLIRNVVMTarget
NVVM/Target.cpp
+ OBJECT
+
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Dialect/LLVMIR
@@ -109,6 +111,8 @@ endif()
add_mlir_dialect_library(MLIRROCDLTarget
ROCDL/Target.cpp
+ OBJECT
+
LINK_COMPONENTS
MCParser
${AMDGPU_LIBS}
diff --git a/mlir/tools/mlir-shlib/CMakeLists.txt b/mlir/tools/mlir-shlib/CMakeLists.txt
index 32fe833cee4ea..a33c70c5807be 100644
--- a/mlir/tools/mlir-shlib/CMakeLists.txt
+++ b/mlir/tools/mlir-shlib/CMakeLists.txt
@@ -34,6 +34,7 @@ if(LLVM_BUILD_LLVM_DYLIB)
add_mlir_library(
MLIR
SHARED
+ EXCLUDE_FROM_LIBMLIR
${INSTALL_WITH_TOOLCHAIN}
mlir-shlib.cpp
${_OBJECTS}
|
|
This patch breaks the build of flang when quad math support is enabled (#81971). Quad math support is off by default (why no buildbot tripper over this), and can be enabled by setting the following cmake variable: -DFLANG_RUNTIME_F128_MATH_LIB=libquadmath With this patch applied, all libquadmath symbols cannot be found during the build: cosq, acoshq, ... |
AlexisPerry
pushed a commit
to llvm-project-tlp/llvm-project
that referenced
this pull request
Jul 9, 2024
As discussed in llvm#89743, when using the Visual Studio solution generators, object library projects are displayed as a collection of non-editable *.obj files. To look for the corresponding source files, one has to browse (or search) to the library's obj.libname project. This patch tries to avoid this as much as possible. For Clang, there is already an exception for XCode. We handle MSVC_IDE the same way. For MLIR, this is more complicated. There are explicit references to the obj.libname target that only work when there is an object library. This patch cleans up the reasons for why an object library is needed: 1. The obj.libname is modified in the calling CMakeLists.txt. Note that with use-only references, `add_library(<name> ALIAS <target>)` could have been used. 2. An `libMLIR.so` (mlir-shlib) is also created. This works by adding linking the object libraries' object files into the libMLIR.so (in addition to the library's own .so/.a). XCode is handled using the `-force_load` linker option instead. Windows is not supported. This mechanism is different from LLVM's llvm-shlib that is created by linking static libraries with `-Wl,--whole-archive` (and `-Wl,-all_load` on MacOS). 3. The library might be added to an aggregate library. In-tree, the seems to be only `libMLIR-C.so` and the standalone example. In XCode, it uses the object library and `-force_load` mechanism as above. Again, this is different from `libLLVM-C.so`. 4. Build an object library whenever it was before this patch, except when generating a Visual Studio solution. This condition could be removed, but I am trying to avoid build breakages of whatever configurations others use. This seems to never have worked with XCode because of the explicit references to obj.libname (reason 1.). I don't have access to XCode, but I tried to preserve the current working. IMHO there should be a common mechanism to build aggregate libraries for all LLVM projects instead of the 4 that we have now. As far as I can see, this means for LLVM there are the following changes on whether object libraries are created: 1. An object library is created even in XCode if FORCE_OBJECT_LIBRARY is set. I do not know how XCode handles it, but I also know CMake will abort otherwise. 2. An object library is created even for explicitly SHARED libraries for building `libMLIR.so`. Again, mlir-shlib does not work otherwise. `libMLIR.so` itself is created using SHARED so this patch is marking it as EXCLUDE_FROM_LIBMLIR. 3. For the second condition, it is now sensitive to whether the mlir-shlib is built at all (LLVM_BUILD_LLVM_DYLIB). However, an object library is still built using the fourth condition unless using the MSVC solution generator. That is, except with MSVC_IDE, when an object library was built before, it will also be an object library now.
Meinersbur
added a commit
that referenced
this pull request
Jul 12, 2024
When the `add_flang_library` was first added, it was apparently copied
over from `add_clang_library`, including its logic to determine the
library type. It includes a workaround: If `BUILD_SHARED_LIBS` is
enabled, it should build all libraries as shared, including those that
are explicitly marked as `STATIC`[^1], because `add_clang_library`
always passes at least one of `STATIC`/`SHARED` to `llvm_add_library`,
and `llvm_add_library` could not distinguish the two cases.
Then, the two implementations diverged. For its runtime libraries, Flang
requires some libraries to always be static libraries, so if a library
is explicitly marked as `STATIC`, `BUILD_SHARED_LIBS` is ignored[^2].
I noticed the two implementations of the same functionality, modified
only the `add_clang_library`, and copied over the result to
`add_flang_library`[^3], without noticing that they are slightly
different. As a result, Flang runtime libraries would be built as shared
libraries with `-DBUILD_SHARED_LIBS=ON`, which may break some build
configurations[^4].
This PR fixes the problem and at the same time simplifies the library
type algorithm by just passing SHARED/STATIC verbatim to
`llvm_add_library`. This is effectively what [^2] should have done
instead adding more code to undo the workaround of [^1]. Ideally, one
would use
```
llvm_add_library(${name} ${ARG_STATIC} ${ARG_SHARED} [...])
```
but `ARG_STATIC`/`ARG_SHARED` as set by `cmake_parse_arguments` contain
`TRUE`/`FALSE` instead of the keywords themselves. I could imagine a
utility function akin to `pythonize_bool` that does this.
This simplification adds two more changes:
1. Object libraries are not explicitly requested anymore.
`llvm_add_library` itself should determine whether an object library is
necessary. As the comment notes, using an object library is not without
problems and seem of no use here since it works fine without object
library when in `XCODE`/`MSVC_IDE` mode.
2. The property `CLANG_STATIC_LIBS` was removed. It was
`FLANG_STATIC_LIBS` before to copy&paste error of #93519 [^3] which not
used anywhere. In clang, `CLANG_STATIC_LIBS` is used for `clang-shlib`
to include all component libraries in a single large library. There is
no equivalent `flang-shlib`.
[^1]: dbc2a12
[^2]: 3d2e05d
[^3]: #93519
[^4]:
#93519 (comment)
aaryanshukla
pushed a commit
to aaryanshukla/llvm-project
that referenced
this pull request
Jul 14, 2024
When the `add_flang_library` was first added, it was apparently copied
over from `add_clang_library`, including its logic to determine the
library type. It includes a workaround: If `BUILD_SHARED_LIBS` is
enabled, it should build all libraries as shared, including those that
are explicitly marked as `STATIC`[^1], because `add_clang_library`
always passes at least one of `STATIC`/`SHARED` to `llvm_add_library`,
and `llvm_add_library` could not distinguish the two cases.
Then, the two implementations diverged. For its runtime libraries, Flang
requires some libraries to always be static libraries, so if a library
is explicitly marked as `STATIC`, `BUILD_SHARED_LIBS` is ignored[^2].
I noticed the two implementations of the same functionality, modified
only the `add_clang_library`, and copied over the result to
`add_flang_library`[^3], without noticing that they are slightly
different. As a result, Flang runtime libraries would be built as shared
libraries with `-DBUILD_SHARED_LIBS=ON`, which may break some build
configurations[^4].
This PR fixes the problem and at the same time simplifies the library
type algorithm by just passing SHARED/STATIC verbatim to
`llvm_add_library`. This is effectively what [^2] should have done
instead adding more code to undo the workaround of [^1]. Ideally, one
would use
```
llvm_add_library(${name} ${ARG_STATIC} ${ARG_SHARED} [...])
```
but `ARG_STATIC`/`ARG_SHARED` as set by `cmake_parse_arguments` contain
`TRUE`/`FALSE` instead of the keywords themselves. I could imagine a
utility function akin to `pythonize_bool` that does this.
This simplification adds two more changes:
1. Object libraries are not explicitly requested anymore.
`llvm_add_library` itself should determine whether an object library is
necessary. As the comment notes, using an object library is not without
problems and seem of no use here since it works fine without object
library when in `XCODE`/`MSVC_IDE` mode.
2. The property `CLANG_STATIC_LIBS` was removed. It was
`FLANG_STATIC_LIBS` before to copy&paste error of llvm#93519 [^3] which not
used anywhere. In clang, `CLANG_STATIC_LIBS` is used for `clang-shlib`
to include all component libraries in a single large library. There is
no equivalent `flang-shlib`.
[^1]: dbc2a12
[^2]: 3d2e05d
[^3]: llvm#93519
[^4]:
llvm#93519 (comment)
Zentrik
added a commit
to Zentrik/llvm-project
that referenced
this pull request
Aug 30, 2024
This reverts commit 6244d87.
|
Hi, this broke the build on windows using mingw and |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in #89743, when using the Visual Studio solution generators, object library projects are displayed as a collection of non-editable *.obj files. To look for the corresponding source files, one has to browse (or search) to the library's obj.libname project. This patch tries to avoid this as much as possible.
For Clang, there is already an exception for XCode. We handle MSVC_IDE the same way.
For MLIR, this is more complicated. There are explicit references to the obj.libname target that only work when there is an object library. This patch cleans up the reasons for why an object library is needed:
The obj.libname is modified in the calling CMakeLists.txt. Note that with use-only references,
add_library(<name> ALIAS <target>)could have been used.An
libMLIR.so(mlir-shlib) is also created. This works by adding linking the object libraries' object files into the libMLIR.so (in addition to the library's own .so/.a). XCode is handled using the-force_loadlinker option instead. Windows is not supported. This mechanism is different from LLVM's llvm-shlib that is created by linking static libraries with-Wl,--whole-archive(and-Wl,-all_loadon MacOS).The library might be added to an aggregate library. In-tree, the seems to be only
libMLIR-C.soand the standalone example. In XCode, it uses the object library and-force_loadmechanism as above. Again, this is different fromlibLLVM-C.so.Build an object library whenever it was before this patch, except when generating a Visual Studio solution. This condition could be removed, but I am trying to avoid build breakages of whatever configurations others use.
This seems to never have worked with XCode because of the explicit references to obj.libname (reason 1.). I don't have access to XCode, but I tried to preserve the current working. IMHO there should be a common mechanism to build aggregate libraries for all LLVM projects instead of the 4 that we have now.
As far as I can see, this means for LLVM there are the following changes on whether object libraries are created:
An object library is created even in XCode if FORCE_OBJECT_LIBRARY is set. I do not know how XCode handles it, but I also know CMake will abort otherwise.
An object library is created even for explicitly SHARED libraries for building
libMLIR.so. Again, mlir-shlib does not work otherwise.libMLIR.soitself is created using SHARED so this patch is marking it as EXCLUDE_FROM_LIBMLIR.For the second condition, it is now sensitive to whether the mlir-shlib is built at all (LLVM_BUILD_LLVM_DYLIB). However, an object library is still built using the fourth condition unless using the MSVC solution generator. That is, except with MSVC_IDE, when an object library was built before, it will also be an object library now.