[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