[all-commits] [llvm/llvm-project] 6244d8: Avoid object libraries in the VS IDE (#93519)

[Michael Kruse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6244d87f42775e8d49cf758eeb1909f2ce144e3c
      https://github.com/llvm/llvm-project/commit/6244d87f42775e8d49cf758eeb1909f2ce144e3c
  Author: Michael Kruse <llvm-project at meinersbur.de>
  Date:   2024-06-19 (Wed, 19 Jun 2024)

  Changed paths:
    M clang/cmake/modules/AddClang.cmake
    M clang/lib/Support/CMakeLists.txt
    M flang/cmake/modules/AddFlang.cmake
    M mlir/cmake/modules/AddMLIR.cmake
    M mlir/lib/Dialect/GPU/CMakeLists.txt
    M mlir/lib/Target/LLVM/CMakeLists.txt
    M mlir/tools/mlir-shlib/CMakeLists.txt

  Log Message:
  -----------
  Avoid object libraries in the VS IDE (#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(<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.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications