Carthage: Swift header file not created correctly when building with Xcode 10.2

[DavidBrunow]

• carthage install method: [ ] .pkg, [ ] homebrew, [x] source
• which carthage: Carthage binary in our path
• carthage version: 0.32.0
• xcodebuild -version: Xcode 10.2
  Build version 10P99q
• Are you using --no-build? no
• Are you using --no-use-binaries? no
• Are you using --use-submodules? no
• Are you using --cache-builds? no
• Are you using --new-resolver? no

Cartfile

internal frameworks I cannot share

Issue

Swift 5 seems to have changed the format of the generated Swift header file by adding the following conditionals dependent on the architecture:

#if 0
#elif defined(__arm64__) && __arm64__
...
#elif defined(__ARM_ARCH_7A__) && __ARM_ARCH_7A__
...

When building the iOS platform with Carthage the generated Swift header file only has __arm64__ and __ARM_ARCH_7A__ but does not have any conditionals for the simulator architectures and therefore the Swift parts of the framework can't be used by Objective C code in the app.

I'm reviewing the Carthage code to find a way to resolve this issue but would appreciate any help pointing me towards the right files.

[DavidBrunow]

Thinking about this more I can think of two different approaches that could be taken:

• Append the contents of the simulator FrameworkName-Swift.h to the end of the device FrameworkName-Swift.h file
• Create separate Build folders for simulators and devices

[tmspzz]

Carthage doesn’t touch any file in your project. This is a problem with your project’s settings.

EDIT:
Narrator: No it wasnt's

[DavidBrunow]

It may be true that it is a problem with my project's settings but I don't believe that to be the case because this dependency builds and can be used with no issues using Xcode 10.1. I understand that Carthage doesn't touch any of the files in the project but I believe that the way that the Swift compiler works for Swift 5 has changed the way that the generated FrameworkName-Swift.h files are created.

I'll create a small sample project to demonstrate the behavior with code that can be shared.

[DavidBrunow]

I created a Small Sample Project and committed the Carthage/Build folder here: https://github.com/DavidBrunow/Small-Sample-Project

If you look at the Alamofire-Swift.h file you will see the issue I am describing: https://github.com/DavidBrunow/Small-Sample-Project/blob/master/Carthage/Build/iOS/Alamofire.framework/Headers/Alamofire-Swift.h

[ikesyo]

Append the contents of the simulator FrameworkName-Swift.h to the end of the device FrameworkName-Swift.h file

I'm for this.

[tmspzz]

This seems like a bug to me in the header generation in Swift 5. Has anyone filed a radar?

[tmspzz]

https://twitter.com/jckarter/status/1102983497193480192?s=21

[DavidBrunow]

~I can't decipher whether this is the intended behavior or not from that Twitter exchange. The sample project I linked to was built with the latest Xcode beta 4.~

Read some more and it looks like this needs to be fixed in Carthage, right?

[tmspzz]

This is a behavior is definitely new.

My understanding is that since the headers that are generated vary per architecture + sdk combination it's not enough anymore to pack the binaries in a fat mach-o but as you suggest we have to pack the header files as well.

See exchange here: https://twitter.com/tmpz/status/1103056707096399876

I'm very surprised by the change. Packing multiple architectures into one binary has been perfectly fine till now. I can think of quite a few businesses that distribute .frameworks this way.

[DavidBrunow]

For the project that I'm working on I've modified our shell script that we have wrapped around Carthage to append the simulator FrameworkName-Swift.h file to the end of the device FrameworkName-Swift.h file. This seems to resolve the issue based upon my initial testing. Looking at the way that the logic is generated in the header files it seems like a simple process to append the missing architectures.

I'm happy to spend a little time updating Carthage to support that functionality if that's the direction that Carthage should go. Would also need a little direction to determine the best place to do that -- from what I've looked at so far it looks like the best place would be in Xcode.swift somewhere around the mergeExecutables(executeableURLs:,outputURL:) method.

[tmspzz]

the best place would be in Xcode.swift somewhere around the mergeExecutables(executeableURLs:,outputURL:) method.

correct

[ikesyo]

I think it would be good to have a separate function which merges headers and then call it in mergeBuildProducts.

[DavidBrunow]

Note: This issue is related to a change in Xcode's behavior in Xcode 10.2 using the new build system and is not related to Swift 5.

[dalemyers]

After speaking to an Apple engineer, the fix should be of the form:

#if TARGET_OS_SIMULATOR
<simulator Swift.h>
#else
<device Swift.h>
#endif

rather than just appending.

Edit: Seems that this is already in the PR. :)

[DavidBrunow]

It isn't in the PR in that particular manner. I'll make that change.

[ikesyo]

Addressed by #2723.

[buranmert]

We still can reproduce the issue after #2723, can we reopen the issue @DavidBrunow ?
We made another fix on top of your fix (#2748) which is still open, I'd suggest closing the issue once that one gets merged and tested

[DavidBrunow]

@buranmert I don't think I have the power to reopen the issue.

Strange that your project needs the TargetConditionals.h and mine doesn't -- would be interesting to know the difference that is causing that.

[AshrafJaddo]

Any other workaround beside manually modifying the header files to add simulator until we get official fix?

[buranmert]

@DavidBrunow quick heads-up: #2748 is finally merged.

i haven't had time to test it actually but i'm wondering if there might be a difference between projects created by Xcode 10.2 and older projects regarding TargetConditionals inclusion problem.

[DavidBrunow]

@buranmert The project I'm working on is old, is yours new?

[DavidBrunow]

@AshrafJaddo You can build Carthage from master as a workaround.

[buranmert]

@DavidBrunow our projects are old too. i have no guess in that case

[Ogerets]

I still have issues on v0.33.0. I can see header now contains define conditionals for simulator architectures, but compiler still can't find declarations of classes from objc code.

[buranmert]

I still have issues on v0.33.0. I can see header now contains define conditionals for simulator architectures, but compiler still can't find declarations of classes from objc code.

@Ogerets can you manually edit the header file to see what works for you by try&error?

[Ogerets]

@buranmert Yep. I realized that for some reason TARGET_OS_SIMULATOR is not set when I build for simulator. Removing condition #if TARGET_OS_SIMULATOR helps. Am I the only one who still can reproduce the issue?

[JetForMe]

This is happening without the #include <TargetConditionals.h> at the top, but 0.33.0 should have that. Is it not in the generated header?

--
Rick Mann
[email protected]

On Apr 9, 2019, at 03:08, Evgeny Pyvovarov [e-mail] wrote:

@buranmert Yep. I realized that for some reason TARGET_OS_SIMULATOR is not set when I build for simulator. Removing condition #if TARGET_OS_SIMULATOR helps. Am I the only one who still have issue?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Ogerets]

This is happening without the #include <TargetConditionals.h> at the top, but 0.33.0 should have that. Is it not in the generated header?
…

It' not there

EDIT:
Ok, it was my fault. I was downloading prebuilt binaries

[tmspzz]

I think this issue can now be closed as 0.33.0 that includes the fix has been released.

Reopen if necessary.