[all-commits] [llvm/llvm-project] 424ad1: [flang] Simplify LIBTYPE logic (#98072)

[Michael Kruse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 424ad163c715e478d37cfd1efaae148cdd6aa815
      https://github.com/llvm/llvm-project/commit/424ad163c715e478d37cfd1efaae148cdd6aa815
  Author: Michael Kruse <llvm-project at meinersbur.de>
  Date:   2024-07-12 (Fri, 12 Jul 2024)

  Changed paths:
    M flang/cmake/modules/AddFlang.cmake

  Log Message:
  -----------
  [flang] Simplify LIBTYPE logic (#98072)

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]: dbc2a12c7311ff4cc2cd7887d128b506bd35b579

[^2]: 3d2e05d542e646891745c5278a09950d3c4fb4a5

[^3]: #93519

[^4]:
https://github.com/llvm/llvm-project/pull/93519#issuecomment-2192359002



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