[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
Zentrik wrote: Hi, this broke the build on windows using mingw and `LLVM_BUILD_LLVM_DYLIB`. See https://github.com/llvm/llvm-project/issues/106899 for more details. Any help fixing this would be appreciated, thanks. https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
Meinersbur wrote: @dpalermo I added fix as PR #98072 https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
dpalermo wrote: This patch breaks the build of flang when quad math support is enabled (https://github.com/llvm/llvm-project/pull/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, ... ``` FAILED: lib/libFortranFloat128Math.so.19.0git : && /usr/bin/c++ -fPIC -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-init ializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-ov erride -Wno-comment -Wno-misleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-copy -Wno-ctad-maybe-unsupported -fno-strict-aliasing -fno-semantic-interposition -fno-lt o -O3 -DNDEBUG -fno-semantic-interposition -Wl,-z,defs -Wl,-z,nodelete -Wl,-rpath-link,/work1/omp-nightly/build/git/trunk19.0/build/llvm-project/./lib -Wl,--gc-sections -shared -Wl,-soname,libFortranFloat1 28Math.so.19.0git -o lib/libFortranFloat128Math.so.19.0git tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/acos.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math .dir/acosh.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/asin.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/asinh.cpp.o tools/flang/runtime/Float 128Math/CMakeFiles/obj.FortranFloat128Math.dir/atan.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/atan2.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math .dir/atanh.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/ceil.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/complex-math.c.o tools/flang/runtime/ Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/cos.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/cosh.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128M ath.dir/erf.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/erfc.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/exp.cpp.o tools/flang/runtime/Float1 28Math/CMakeFiles/obj.FortranFloat128Math.dir/exponent.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/floor.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128M ath.dir/fma.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/fraction.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/hypot.cpp.o tools/flang/runtime/ Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/j0.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/j1.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math .dir/jn.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/lgamma.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/llround.cpp.o tools/flang/runtime/Floa t128Math/CMakeFiles/obj.FortranFloat128Math.dir/log.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/log10.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math .dir/lround.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/mod-real.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/modulo-real.cpp.o tools/flang/ru ntime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/nearest.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/norm2.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.Fortr anFloat128Math.dir/pow.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/random.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/round.cpp.o tools/flang /runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/rrspacing.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/scale.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj. FortranFloat128Math.dir/set-exponent.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/sin.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/sinh.cpp.o t ools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/spacing.cpp.o tools/flang/runtime/Float128Math/CMakeFiles/obj.FortranFloat128Math.dir/sqrt.cpp.o tools/flang/runtime/Float128Math/CMakeFil es/obj.FortranFloat128Math.dir/tan.cpp.o tools/flang/
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur closed https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/AaronBallman approved this pull request. LGTM, thank you! https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
llvmbot wrote: @llvm/pr-subscribers-mlir-llvm Author: Michael Kruse (Meinersbur) Changes 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: 1. The obj.libname is modified in the calling CMakeLists.txt. Note that with use-only references, `add_library(ALIAS )` could have been used. 2. An libMLIR.so (mlir-shlib) is also created. This works by adding linking the object libraries' object file into libMLIR.so (in addition to the library's own .so/.a). XCode is handled using the `-force_load` linker option instead. Windows is not even 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. 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 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: 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 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. --- Full diff: https://github.com/llvm/llvm-project/pull/93519.diff 7 Files Affected: - (modified) clang/cmake/modules/AddClang.cmake (+5-1) - (modified) clang/lib/Support/CMakeLists.txt (+1-1) - (modified) flang/cmake/modules/AddFlang.cmake (+15-6) - (modified) mlir/cmake/modules/AddMLIR.cmake (+42-20) - (modified) mlir/lib/Dialect/GPU/CMakeLists.txt (+2) - (modified) mlir/lib/Target/LLVM/CMakeLists.txt (+4) - (modified) mlir/tools/mlir-shlib/CMakeLists.txt (+1) ``diff 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_fl
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
llvmbot wrote: @llvm/pr-subscribers-mlir-core @llvm/pr-subscribers-mlir-gpu Author: Michael Kruse (Meinersbur) Changes 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: 1. The obj.libname is modified in the calling CMakeLists.txt. Note that with use-only references, `add_library(ALIAS )` could have been used. 2. An libMLIR.so (mlir-shlib) is also created. This works by adding linking the object libraries' object file into libMLIR.so (in addition to the library's own .so/.a). XCode is handled using the `-force_load` linker option instead. Windows is not even 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. 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 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: 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 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. --- Full diff: https://github.com/llvm/llvm-project/pull/93519.diff 7 Files Affected: - (modified) clang/cmake/modules/AddClang.cmake (+5-1) - (modified) clang/lib/Support/CMakeLists.txt (+1-1) - (modified) flang/cmake/modules/AddFlang.cmake (+15-6) - (modified) mlir/cmake/modules/AddMLIR.cmake (+42-20) - (modified) mlir/lib/Dialect/GPU/CMakeLists.txt (+2) - (modified) mlir/lib/Target/LLVM/CMakeLists.txt (+4) - (modified) mlir/tools/mlir-shlib/CMakeLists.txt (+1) ``diff 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 @@ -5
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur ready_for_review https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
AaronBallman wrote: I applied the patch locally and tried it out, and I think this is an improvement for folks generating VS solutions. https://github.com/llvm/llvm-project/pull/93519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [mlir] Avoid object libraries in the VS IDE (PR #93519)
https://github.com/Meinersbur created
https://github.com/llvm/llvm-project/pull/93519
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:
1. The obj.libname is modified in the calling CMakeLists.txt. Note that with
use-only references, `add_library( ALIAS )` could have been used.
2. An libMLIR.so (mlir-shlib) is also created. This works by adding linking the
object libraries' object file into libMLIR.so (in addition to the library's own
.so/.a). XCode is handled using the `-force_load` linker option instead.
Windows is not even 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. 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 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:
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 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.
>From a08815e3b5e204c4f7eccbfbfcdb04d00ab7f895 Mon Sep 17 00:00:00 2001
From: Michael Kruse
Date: Tue, 28 May 2024 09:50:21 +0200
Subject: [PATCH] Avoid object libraries in the VS IDE
---
clang/cmake/modules/AddClang.cmake | 6 ++-
clang/lib/Support/CMakeLists.txt | 2 +-
flang/cmake/modules/AddFlang.cmake | 21 +++---
mlir/cmake/modules/AddMLIR.cmake | 62 +++-
mlir/lib/Dialect/GPU/CMakeLists.txt | 2 +
mlir/lib/Target/LLVM/CMakeLists.txt | 4 ++
mlir/tools/mlir-shlib/CMakeLists.txt | 1 +
7 files changed, 70 insertions(+), 28 deletions(-)
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.cma
