Emit Swift header file to two different locations

[fkorotkov]

Xcode for example doesn't allow to use "ModuleName-Swift.h" syntax but only "ModuleName/ModuleName-Swift.h"

[facebook-github-bot]

@fkorotkov updated the pull request - view changes

[facebook-github-bot]

@Coneko has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[Coneko]

This doesn't make the header exported though, it only changes the include path.
Note that since it currently is a private header, not an exported header, including it with just the header name is more idiomatic.

[fkorotkov]

@Coneko it's not actually an exported header, it's true. Maybe my comment is misleading but my intention was to make it consistent with Xcode behaviour.

I agree that it's more idiomatic to include with just a header name. But that's make it way harder to migrate an existing application from Xcode to Buck(our app for example is ~500K LOC of Swift and ObjC mix). We can try to change our code base to follow such best practices but third party libraries is another case.

How do you guys handle third party libraries? Or you don't have any Swift/ObjC libraries?

[Coneko]

make it consistent with Xcode behaviour

The part about exporting the header to other targets, or the part where the include path is like an exported headers even though it's a private header?

I personally don't use swift so I don't know how Xcode behaves in that regard, I just followed the objc convention of importing headers from the same library as "Header.h" and headers from other libraries as <Library/Header.h>.

I don't mind adding the possibility to import it with <Library/Header.h> if we make it exported, but changing the import path without exporting it will only make it look like it would work, not actually make it work. For example if you #import <Library/Library-Swift.h> in a public header of the library then include from another target I don't think it would work.

cc @ryu2, @robbertvanginkel, @nguyentruongtho

[nguyentruongtho]

It shouldn't be an exported header. Generated headers are to be seen from targets that depend on the swift target containing generated header (if that swift target is a module, require module enabled) via modulemap.

[robbertvanginkel]

The difference here should be in mixed app targets vs mixed framework targets. I don't think this can be decided from the level of SwiftCompile.java. Relevant apple doc, especially the import matrixes https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html

When doing imports with "ModuleName/ModuleName-Swift.h", what are you importing from where? (app importing own swift?, app importing deps' swift?, framework importing own swift?, framework importing deps' swift?)

[fkorotkov]

@robbertvanginkel it comes from the same target. Here is an example of a pod that I tried to move to Buck: https://github.com/Quick/Nimble/blob/master/Sources/NimbleObjectiveC/DSL.m#L2

How do you handle third party? Do you fork or maybe pre-built them?

[fkorotkov]

@Coneko how do you think I can approach this issue? It's blocking us from using Nimble and Quick without forking them.

I can't use the same technique with creating symlinks like for normal headers because I need to compile sources to emit the header.

Do you think it make sense to create another flavor that depends on swift-compile and then provide both of rules(with swift-companion) for mixed targets from SwiftLibraryDescription#createCompanionBuildRule method?

[facebook-github-bot]

@fkorotkov updated the pull request - view changes - changes since last import

[fkorotkov]

just a quick update: we started using a fork with this change internally and it proved to unblock us from many issues we've seen. We are able now to maintain Buck and Xcode builds at the same time with minimum changes to the code.

This change might not be the ideal solution but it definitly works :-)

[milend]

The Swift generated header is now compiled before any dependents and I don't believe this issue is affecting master anymore (using mixed apple_library).