[libcxx-commits] [PATCH] D120719: [runtimes] Always configure libc++abi before libc++
Louis Dionne via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Fri May 6 07:04:06 PDT 2022
ldionne added a comment.
In D120719#3438306 <https://reviews.llvm.org/D120719#3438306>, @phosek wrote:
> [...]
> You can use the same technique for include directories:
>
> cmake_minimum_required(VERSION 3.13.4)
> project(Test C)
>
> add_library(A STATIC a.c)
> target_include_directories(A PUBLIC "include/a")
>
> add_library(C SHARED c.c)
> target_link_libraries(C PRIVATE "$<GENEX_EVAL:$<TARGET_LINKER_FILE:B>>")
> target_include_directories(C PRIVATE "$<GENEX_EVAL:$<TARGET_PROPERTY:B,INCLUDE_DIRECTORIES>>")
>
> add_library(B IMPORTED STATIC)
> set_target_properties(B PROPERTIES IMPORTED_LOCATION "$<TARGET_LINKER_FILE:A>")
> set_target_properties(B PROPERTIES INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:A,INCLUDE_DIRECTORIES>")
>
> Is that what you had in mind?
Right, this technically works, however it's kind of crazy to have to do this instead of just `target_link_libraries(C PRIVATE B)`. I don't think that's a viable way to move forward. Furthermore, concretely there isn't that much of a downside in hardcoding an order between libc++ and libc++abi. There's also precedent for doing this with compiler-rt.
So.. yes, technically we can make it work without enforcing an order, however targets that use `libcxx-abi-shared` & friends in D120727 <https://reviews.llvm.org/D120727> will have to do it in a really awkward way.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D120719/new/
https://reviews.llvm.org/D120719
More information about the libcxx-commits
mailing list