-
Notifications
You must be signed in to change notification settings - Fork 11.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[libc++abi] Use target_compile_options to pass LIBCXXABI_ADDITIONAL_COMPILE_FLAGS #96112
[libc++abi] Use target_compile_options to pass LIBCXXABI_ADDITIONAL_COMPILE_FLAGS #96112
Conversation
…OMPILE_FLAGS We use target_compile_options to pass the libc++ variant of this flag, so we should be consistent for libc++abi. This is actually not only a matter of consistency: target_compile_options handles duplicate CMake options in a certain way (it removes duplicates but has an escape hatch using the "SHELL:" prefix), and it is important for both libc++ and libc++abi options to be handled in the same way.
@llvm/pr-subscribers-libcxxabi Author: Louis Dionne (ldionne) ChangesWe use target_compile_options to pass the libc++ variant of this flag, so we should be consistent for libc++abi. This is actually not only a matter of consistency: target_compile_options handles duplicate CMake options in a certain way (it removes duplicates but has an escape hatch using the "SHELL:" prefix), and it is important for both libc++ and libc++abi options to be handled in the same way. Full diff: https://github.com/llvm/llvm-project/pull/96112.diff 2 Files Affected:
diff --git a/libcxxabi/CMakeLists.txt b/libcxxabi/CMakeLists.txt
index 52ba52f3439fb..43400c6e8d9af 100644
--- a/libcxxabi/CMakeLists.txt
+++ b/libcxxabi/CMakeLists.txt
@@ -244,7 +244,6 @@ if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")
add_flags_if_supported("-mdefault-visibility-export-mapping=explicit")
set(CMAKE_AIX_EXPORT_ALL_SYMBOLS OFF)
endif()
-add_compile_flags("${LIBCXXABI_ADDITIONAL_COMPILE_FLAGS}")
add_library_flags("${LIBCXXABI_ADDITIONAL_LIBRARIES}")
# Configure compiler. Must happen after setting the target flags.
diff --git a/libcxxabi/src/CMakeLists.txt b/libcxxabi/src/CMakeLists.txt
index c54ced4dc3ea8..d6fcd72dcb1bd 100644
--- a/libcxxabi/src/CMakeLists.txt
+++ b/libcxxabi/src/CMakeLists.txt
@@ -182,6 +182,7 @@ set_target_properties(cxxabi_shared_objects
if (CMAKE_POSITION_INDEPENDENT_CODE OR NOT DEFINED CMAKE_POSITION_INDEPENDENT_CODE)
set_target_properties(cxxabi_shared_objects PROPERTIES POSITION_INDEPENDENT_CODE ON) # must set manually because it's an object library
endif()
+target_compile_options(cxxabi_shared_objects PUBLIC "${LIBCXXABI_ADDITIONAL_COMPILE_FLAGS}")
if (LIBCXXABI_ENABLE_SHARED)
add_library(cxxabi_shared SHARED)
@@ -261,6 +262,7 @@ set_target_properties(cxxabi_static_objects
CXX_STANDARD_REQUIRED OFF # TODO: Make this REQUIRED once we don't need to accommodate the LLVM documentation builders using an ancient CMake
COMPILE_FLAGS "${LIBCXXABI_COMPILE_FLAGS}"
)
+target_compile_options(cxxabi_static_objects PUBLIC "${LIBCXXABI_ADDITIONAL_COMPILE_FLAGS}")
if(LIBCXXABI_HERMETIC_STATIC_LIBRARY)
target_add_compile_flags_if_supported(cxxabi_static_objects PRIVATE -fvisibility=hidden)
|
Unfortunately this breaks our buids which use The
@ldionne Can this be reverted back until we find an alternative way to separate |
Reverting this patch will break us :-). I think we can find a way to fix this forward though. It seems like these flags should be added as
|
Yes, it does thank you for the suggestion. The PRIVATE parameter fixed the issue. I created new PR for this in #97608 |
This is the continuation of #96112 which implements proposal from Louis. Using PRIVATE option on target_compile_options() fixes the issue of propagating the option into lib++.
This is the continuation of llvm#96112 which implements proposal from Louis. Using PRIVATE option on target_compile_options() fixes the issue of propagating the option into lib++.
…OMPILE_FLAGS (llvm#96112) We use target_compile_options to pass the libc++ variant of this flag, so we should be consistent for libc++abi. This is actually not only a matter of consistency: target_compile_options handles duplicate CMake options in a certain way (it removes duplicates but has an escape hatch using the "SHELL:" prefix), and it is important for both libc++ and libc++abi options to be handled in the same way.
We use target_compile_options to pass the libc++ variant of this flag, so we should be consistent for libc++abi. This is actually not only a matter of consistency: target_compile_options handles duplicate CMake options in a certain way (it removes duplicates but has an escape hatch using the "SHELL:" prefix), and it is important for both libc++ and libc++abi options to be handled in the same way.