1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

CMake: Add partial fixes for archiving dSYMs with an Xcode project

Browse Source 
CMake by default uses the Release configuration for the Xcode archiving
task, providing no way to choose a different configuration. CMake also
sets the "generate debugging symbols" Xcode option aka the -g flag to
NO for the Release config, because it is not the RelWithDebInfo
config. This means that by default the archived project will never have
debugging symbols.

Change the GCC_GENERATE_DEBUGGING_SYMBOLS Xcode attribute to YES for
all the release configs (Release, MinSizeRel, RelWithDebInfo), as well
as the debug config. This matches the defaults of a project created
in Xcode directly and ensures debug symbols are generated for all
configs.

Another issue is that the Xcode project generated by CMake shows no
values for the debugging format option, which is controlled by the
DEBUG_INFORMATION_FORMAT attribute. In contrast a project created in
Xcode directly, sets the Debug config format to "dwarf" and the
Release config format to "dwarf-with-dsym".
This prevents inclusion of the dSYMs into the archive, because the
dSYM would not be created in the first place.

Override the DEBUG_INFORMATION_FORMAT per-config. The release configs
get the 'dwarf-with-dsym' variant, while the debug config will have
'dwarf'.
This matches the values of a new project created directly in Xcode.

Each of these assignments can be opted out by setting one of the
following variables:
- QT_NO_SET_XCODE_DEBUG_INFORMATION_FORMAT
- QT_NO_SET_XCODE_GCC_GENERATE_DEBUGGING_SYMBOLS

These changes improve the defaults for a CMake generated Xcode
project, but are not sufficient to ensure that dSYMs are included into
the archive created by the Xcode archiving task.

For that, the project also needs to set the CONFIGURATION_BUILD_DIR
attribute to '$(inherited)' to avoid a bug in Xcode, where it can't
copy dSYMs out of a non-inherited build dir into the archive.
Qt can't do that unconditionally, because it violates CMake's build
path preconditions, resulting in things like $<TARGET_FILE:app> genex
evaluation not working, as well as ignoring of the
CMAKE_RUNTIME_OUTPUT_DIRECTORY property.

A follow up change will provide an opt-in to do that, but only at the
project developer's own risk.

[ChangeLog][CMake] CMake-generated Xcode projects will now include
debugging symbols by default, regardless of configuration type, and
Release-like configurations will default to using dSYM bundles instead
of keeping the debug symbols in object files, to match Xcode project
defaults.

Pick-to: 6.7
Task-number: QTBUG-126866
Change-Id: Ie17b40e53ba22658a098f9a162c7bcfb1711c45b
Reviewed-by:  Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 7ccf30ae46272ace13bedc33ccf5f116ff57091b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This commit is contained in:
Alexandru Croitor 2024-07-05 19:09:29 +02:00 committed by Qt Cherry-pick Bot
parent 9775f52cd5
commit 2347afc419
1 changed files with 39 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
cmake/QtPublicAppleHelpers.cmake
View File

@ -499,6 +499,42 @@ function(_qt_internal_set_xcode_install_path target)
endif()
endfunction()
# Explicitly set the debug information format for each build configuration to match the values
# of a new project created via Xcode directly. This ensures debug information is included during
# archiving.
function(_qt_internal_set_xcode_debug_information_format target)
if(NOT DEFINED CMAKE_XCODE_ATTRIBUTE_DEBUG_INFORMATION_FORMAT
AND NOT QT_NO_SET_XCODE_DEBUG_INFORMATION_FORMAT)
get_target_property(existing "${target}" XCODE_ATTRIBUTE_DEBUG_INFORMATION_FORMAT)
if(NOT existing)
# The CMake Xcode generator searches for [variant=${config}], removes that substring,
# and generates the attribute only for the config that is specified as the "variant".
set_target_properties("${target}" PROPERTIES
"XCODE_ATTRIBUTE_DEBUG_INFORMATION_FORMAT[variant=Debug]" "dwarf")
set_target_properties("${target}" PROPERTIES
"XCODE_ATTRIBUTE_DEBUG_INFORMATION_FORMAT[variant=Release]" "dwarf-with-dsym")
set_target_properties("${target}" PROPERTIES
"XCODE_ATTRIBUTE_DEBUG_INFORMATION_FORMAT[variant=MinSizeRel]" "dwarf-with-dsym")
set_target_properties("${target}" PROPERTIES
"XCODE_ATTRIBUTE_DEBUG_INFORMATION_FORMAT[variant=RelWithDebInfo]"
"dwarf-with-dsym")
endif()
endif()
endfunction()
# Make sure to always generate debug symbols, to match the values of a new project created via
# Xcode directly.
function(_qt_internal_set_xcode_generate_debugging_symbols target)
if(NOT DEFINED CMAKE_XCODE_ATTRIBUTE_GCC_GENERATE_DEBUGGING_SYMBOLS
AND NOT QT_NO_SET_XCODE_GCC_GENERATE_DEBUGGING_SYMBOLS)
get_target_property(existing "${target}" XCODE_ATTRIBUTE_GCC_GENERATE_DEBUGGING_SYMBOLS)
if(NOT existing)
set_target_properties("${target}" PROPERTIES
"XCODE_ATTRIBUTE_GCC_GENERATE_DEBUGGING_SYMBOLS" "YES")
endif()
endif()
endfunction()
function(_qt_internal_set_xcode_bundle_display_name target)
# We want the value of CFBundleDisplayName to be ${PRODUCT_NAME}, but we can't put that
# into the Info.plist.in template file directly, because the implicit configure_file(Info.plist)
@ -922,6 +958,9 @@ function(_qt_internal_finalize_apple_app target)
_qt_internal_set_xcode_code_sign_style("${target}")
_qt_internal_set_xcode_bundle_display_name("${target}")
_qt_internal_set_xcode_install_path("${target}")
_qt_internal_set_xcode_configuration_build_dir("${target}")
_qt_internal_set_xcode_debug_information_format("${target}")
_qt_internal_set_xcode_generate_debugging_symbols("${target}")
endif()
_qt_internal_set_xcode_bundle_name("${target}")