Closed kikeenrique closed 2 years ago
Hello,
i have the exact same issue. Any news on this one? Thanks
I can just update report info. I've updated the example repo to tuist 3.0 and Xcode 13.2.1 and stills fails to build. Logs in https://github.com/kikeenrique/tuist-spm-sdwebimageswiftui-fails/runs/5536077748
Thanks for the update, I think there is some problem when an Objc target depends on an SPM dependency with modulemap, as I suspect that the -fmodule-map-file
only works on swift targets 🤔
We would need to investigate it more and find a solution 🙏
For everyone who wants to implement the workaround mentioned in #4255 you need to add "HEADER_SEARCH_PATHS": "$(inherited) $(SRCROOT)/SDWebImage/include/SDWebImage $(SRCROOT)/SDWebImage/Private $(SRCROOT)/SDWebImage/Core $(SRCROOT)/WebImage"
to the SDWebImage dependency target settings and everything works fine (for now and Xcode 13.2.1)
I don't really get where exactly should I add the HEADER_SEARCH_PATHS definition using the reported example repository https://github.com/kikeenrique/tuist-spm-sdwebimageswiftui-fails Any help?
Hey @kikeenrique, we have multiple options when adding settings to targets. You can do it at project level, but in this case this won't help with external dependencies. But tuist provides an option to set settings for external dependencies. My current setup is summed up by this example:
let dependencies = Dependencies(
swiftPackageManager: SwiftPackageManagerDependencies(
[
.remote(url: "https://github.com/SDWebImage/SDWebImageSwiftUI.git", requirement: .exact("2.0.2"))
// all your other dependencies
],
baseSettings: makeFrameworkSettings(),
targetSettings: makeTargetSettings()
)
)
public static func makeTargetSettings() -> [String: SettingsDictionary] {
var settings: [String: SettingsDictionary] = [:]
let allYourDependencyNames = ["SDWebImage"] // add all other dependency names here, this is at least what I am doing
allYourDependencyNames.forEach { dependency in
settings[dependency] = makeBaseSettings()
settings[dependency] = ["HEADER_SEARCH_PATHS": "$(inherited) $(SRCROOT)/SDWebImage/include/SDWebImage $(SRCROOT)/SDWebImage/Private $(SRCROOT)/SDWebImage/Core $(SRCROOT)/WebImage"]
}
return settings
}
static func makeFrameworkSettings() -> Settings {
.settings(
base: makeFrameworkBaseSettings(),
configurations: [
// just an example
.debug(name: "Debug"),
.release(name: "AdHoc"),
.release(name: "Release")
]
)
}
// this is a workaround for named configuration that are different to "Debug" and "Release".
static func makeFrameworkBaseSettings() -> SettingsDictionary {
[
"FRAMEWORK_SEARCH_PATHS": "$(inherited) $(SYMROOT)/Release$(EFFECTIVE_PLATFORM_NAME)"
]
}
static func makeBaseSettings() -> SettingsDictionary {
SettingsDictionary()
.marketingVersion(C.version)
.currentProjectVersion(C.currentBuild)
.swiftVersion(C.swiftVersion)
.swiftOptimizeObjectLifetimes(false)
.bitcodeEnabled(true)
.merging([
"OTHER_LDFLAGS": "-ObjC",
"PUSH_URL_SCHEME": "fressnapfapp",
"ALWAYS_SEARCH_USER_PATHS": "NO",
.... you other settings here
])
}
So, currently I set project settings for every project + set explicits settings for every external dependency. Additionally just for SDWebImage I add the HEADER_SEARCH_PATHS. I hope that helps!
Is there any progress? The same issue with GRPC (CNIOBoringSSL)
The latest library in our project which has to be integrated via spm instead of dependency.swift
Same issue with CNIOBoringSSL
Today I've reviewing the original issue. And... it's been fixed in some release (currently 3.8.0 in CI jobs). I've two CI jobs that have passed build+test using both approaches
basic external SPM dependency https://github.com/kikeenrique/tuist-spm-sdwebimageswiftui-fails/actions/runs/2763414507
let dependencies = Dependencies(
swiftPackageManager: .init(
[.remote(url: "https://github.com/SDWebImage/SDWebImageSwiftUI/",
requirement: .upToNextMajor(from: "2.0.2"))
])
)
basic external SPM dependency ( +headers paths definitions.) https://github.com/kikeenrique/tuist-spm-sdwebimageswiftui-fails/actions/runs/2760406202
func makeBaseSettings() -> SettingsDictionary {
SettingsDictionary()
.swiftOptimizeObjectLifetimes(false)
.bitcodeEnabled(true)
.merging([
"OTHER_LDFLAGS": "-ObjC",
"ALWAYS_SEARCH_USER_PATHS": "NO",
])
}
func makeTargetSettings() -> [String: SettingsDictionary] { var settings: [String: SettingsDictionary] = [:] let allYourDependencyNames = ["SDWebImage"] // add all other dependency names here, this is at least what I am doing allYourDependencyNames.forEach { dependency in settings[dependency] = makeBaseSettings() settings[dependency] = ["HEADER_SEARCH_PATHS": "$(inherited) $(SRCROOT)/SDWebImage/include/SDWebImage $(SRCROOT)/SDWebImage/Private $(SRCROOT)/SDWebImage/Core $(SRCROOT)/WebImage"] }
return settings
}
func makeFrameworkSettings() -> Settings { .settings( base: makeFrameworkBaseSettings() ) }
// this is a workaround for named configuration that are different to "Debug" and "Release". func makeFrameworkBaseSettings() -> SettingsDictionary { [ "FRAMEWORK_SEARCH_PATHS": "$(inherited) $(SYMROOT)" ] }
let dependencies = Dependencies( swiftPackageManager: .init( [.remote(url: "https://github.com/SDWebImage/SDWebImageSwiftUI/", requirement: .upToNextMajor(from: "2.0.2") ) ], baseSettings: makeFrameworkSettings(), targetSettings: makeTargetSettings()) )
Thanks for reporting @kikeenrique !
@pepicrft
Is there still nothing resolved in Tuist regarding this?
Is setting HEADER_SEARCH_PATHS
for headers of all Objc libraries like this is the only solution for now?
@sanghyeok-kim some packages that contain Swift protocols or Objective-C categories might require that upstream targets include the -ObjC
OTHER_LDFLAGS
to prevent the linker from stripping too much. Unfortunately, we can't know with certainty how to reliably apply the flags ourselves. Projects like Bazel and CocoaPods did so and ended up reverting it. However, note that the package authors can make some changes in their packages for the integration to work without requiring you to use the flag. If you tell me which package is causing issues, I can open a PR in it.
@sanghyeok-kim some packages that contain Swift protocols or Objective-C categories might require that upstream targets include the
-ObjC
OTHER_LDFLAGS
to prevent the linker from stripping too much. Unfortunately, we can't know with certainty how to reliably apply the flags ourselves. Projects like Bazel and CocoaPods did so and ended up reverting it. However, note that the package authors can make some changes in their packages for the integration to work without requiring you to use the flag. If you tell me which package is causing issues, I can open a PR in it.
I found the relevant history, and now I can understand what you've described. Thank you :)
Describe the bug I created a dummy project depending on SDWebImageSwiftUI using SPM interface, and when I try build it, it fails.
Error logs are like this:
To Reproduce Steps to reproduce the behavior:
I've created a repo to reproduce the behaviour, also with CI added, but it's just needed to add SDWebImageSwiftUI in Dependencies.swift . https://github.com/kikeenrique/tuist-spm-sdwebimageswiftui-fails
In this job you could see the full compilation logs. https://github.com/kikeenrique/tuist-spm-sdwebimageswiftui-fails/runs/4365023568
Expected behavior SPM package compiles without failure.
Desktop:
Additional context I've also used a dummy project with SDWebImageSwiftUI as SPM dependency and it builds properly. I've traced down xcodebuild to a single compilation file to compare and spot differences on xcodebuild arguments. There are no much differences, but there is one that caught my eyes :
This is the DerivedData for Xcode SPM variant:
This is the DerivedData for Tuist: