Allow users to use custom xcconfig files, which import the generated xcconfigs and make further definitions based on the values contained in those, as injecting manual integrated dependencies.
This is based on a previous disucssion in https://github.com/CocoaPods/CocoaPods/issues/1212.
PODS_ROOTGCC_PREPROCESSOR_DEFINITIONS, OTHER_SWIFT_FLAGSLD_RUNPATH_SEARCH_PATHS, EMBEDDED_CONTENT_CONTAINS_SWIFT$(inherited) to the value of each settingHEADER_SEARCH_PATHS = "${PODS_ROOT}/Headers"
should be:
PODS_HEADER_SEARCH_PATHS = "${PODS_ROOT}/Headers"
HEADER_SEARCH_PATHS = ${PODS_HEADER_SEARCH_PATHS}
This should also cover #2387.
Is the $(inherited) issue going to be fixed in the next Cocoapods release?
Looking forward to not having to copy that constantly each time I do pod install
Since there is no reference to OTHER_LDFLAGS, but this issue supersedes #1212 here is my request to make that explicit.
Note that we can't add $(inherited) to singular build settings -- only the plural ones
FWIW, here's a bit of a hacktastic workaround that renames all values exported by pods to PODS_ variants (assuming you want to manage it yourself):
# CocoaPods-managed variables that you should support.
#
# If CocoaPods adds one not in this list, an error will be thrown to let you know.
EXPECTED_KEYS = ['FRAMEWORK_SEARCH_PATHS', 'GCC_PREPROCESSOR_DEFINITIONS', 'HEADER_SEARCH_PATHS', 'OTHER_CFLAGS', 'OTHER_LDFLAGS', 'PODS_ROOT'].sort
post_install do |installer|
installer.aggregate_targets.each do |target|
next unless target.native_target and target.label.start_with? 'Pods-'
target.native_target.build_configurations.each do |config|
config_path = target.xcconfig_path(config.name)
config_data = config_path.read
keys = config_data.each_line.map {|l| l.sub(/(^.*?)\s*=.*$/, '\1').strip }
unknown_keys = keys - EXPECTED_KEYS
if unknown_keys.size > 0
raise "Encountered unknown xcconfig key(s) (from CocoaPods): #{unknown_keys.join(', ')}"
end
# Ensure that every value is prefixed with PODS_
config_data.gsub! /^(?!PODS_)(.*)$/, 'PODS_\1'
File.write(config_path, config_data)
end
end
end
I updated this issue's title and description to reflect the goal of the proposed change. Furthermore this is only relevant to the user / aggregate target xcconfigs and not to pod target xcconfigs, as those aren't shared with any user targets and so shouldn't be subject to any overwrites.
Please note: What was proposed in #2387, can't be covered anymore with the way pod targets are generated, as those definitions have to be generated individually per target.
So what's the status? I came from #1212 but found no solution here...
Same here. How do you do this?
In Cocoapods v1.6.0 native_target have been removed.
Updated script looks like:
installer.target_installation_results.each do |result|
result.each do |name, installation_result|
next unless installation_result.native_target and name.start_with? 'Pods-'
target = installation_result.target
installation_result.native_target.build_configurations.each do |config|
config_path = target.xcconfig_path(config.name)
config_data = config_path.read
keys = config_data.each_line.map {|l| l.sub(/(^.*?)\s*=.*$/, '\1').strip }
unknown_keys = keys - EXPECTED_KEYS
if unknown_keys.size > 0
raise "Encountered unknown xcconfig key(s) (from CocoaPods): #{unknown_keys.join(', ')} in #{target.label} - #{config.name} "
end
# Ensure that every value is prefixed with PODS_
config_data.gsub! /^(?!PODS_)(.*)$/, 'PODS_\1'
File.write(config_path, config_data)
end
end
end
@ManWithBear does your workaround still work -- this year? I think CocoaPods as of 2020 no longer prefixes the target names with Pods- :(
@fbartho we still using it in our project
Most helpful comment
So what's the status? I came from #1212 but found no solution here...