Modules break the compilation of some Pods #1575

Closed
fabiopelosin opened this Issue Nov 11, 2013 · 19 comments

7 participants

@fabiopelosin
CocoaPods member

It is still unclear under which conditions modules affect the compilation of Pods. What is certain is that in some cases they create issues.

For example Kiwi on OS X is one of the affected Pods.

@fabiopelosin
CocoaPods member

This could be caused by the inclusion of system frameworks via the prefix header.

@orta
CocoaPods member

Anecdote; I had to turn them off on my app because it wouldn't compile with them enabled.

@fabiopelosin
CocoaPods member

Alternatively we could disable them until they are not further understood or haven't matured.

@swizzlr

came here from 1629: I think this is a bug in Xcode – i'm often manually clearing the ModuleCache.

@rivera-ernesto rivera-ernesto referenced this issue in CocoaPods/cocoapods-integration-specs Mar 18, 2014
Closed

Make warning flags less aggressive: "Warn and treat as error" -> "Warn" #7

@Daniel1of1

If it's of any use - as of Xcode 5.1 cannot reproduce any errors, at least with Kiwi OS X.

@CocoaPodsBot

Issue has been confirmed by @confidenceJuice

@rivera-ernesto

Still an issue with some Pods, such as Cordova 2.x.

@fabiopelosin
CocoaPods member

Thanks @confidenceJuice.

According to my commented in Xcodeproj this issue should be fixed in CocoaPods.

However I'm a bit on the fence, at the time I enabled them on Xcodeproj because I couldn't see any issue and since 5.1 they are enabled in Xcode as well (and thus one could infer that they are considered mature enough). Moreover some Pods might have started using the @import syntax and changing the setting would break them. Therefore I'm not sure about what would be a lesser harm.

So my question is, should they be disabled at the podspec level/directly by the user (when the support for the xcconfigs will be available) or should they be disabled in CocoaPods?

@rivera-ernesto can't the podspec of Cordova 2.x be updated to disable the modules?

@kylef

@irrationalfab Some pod's definitely do use it. ChuzzleKit spec, source is one example.

@fabiopelosin
CocoaPods member

So this pretty much rules out the option of disabling it... because we will just create confusion among the users who depended on the current CP behaviour or that accommodated for it.

Any report about the other options being viable?

@rivera-ernesto

Turns out that:

  • There's no need to explicitly use @module as #import <> will do the same when modules are enabled. Thus the former would be good even for the libraries @kylef mentioned for compatibility (for instance people manually adding the files to their non-modules-enabled projects).
  • Modules only work with Apple's first party libraries.
  • But seems like if a module.map is generated (by CocoaPods?!!!), then modules also work with 3rd party libraries.
@rivera-ernesto

In the mean time I'll try to find out why some libraries break with modules...

@fabiopelosin
CocoaPods member

There's no need to explicitly use @module as #import <> will do the same when modules are enabled. Thus the former would be good even for the libraries @kylef mentioned for compatibility (for instance people manually adding the files to their non-modules-enabled projects).

I'm aware of this, but I don't see people holding off from syntactic sugar for backward compatibility... Moreover, it is simply too late, libraries using this syntax are already used in production, so we cannot just break them and tell them to change their syntax.

Modules only work with Apple's first party libraries.

Still they provide syntactic sugar and speed up build times.

But seems like if a module.map is generated (by CocoaPods?!!!), then modules also work with 3rd party libraries.

I preliminarily investigated this option in the past and didn't further proceed with it because it is not supported and, given the issues, I considered modules not mature enough (maybe there were also other considerations related to how CocoaPods builds the libraries).

@fabiopelosin
CocoaPods member

In the mean time I'll try to find out why some libraries break with modules...

That would be awesome. Also did you investigate if disabling them via the XCConfig of the specification is a viable alternative?

Btw, if I recall correctly, modules don't like imports of system frameworks via prefix headers (I think this was the issue with Kiwi).

@rivera-ernesto

This seems to no longer be an issue as of 0.32.1.

Some not directly related fixes may have solved this.

@fabiopelosin
CocoaPods member

If I recall correctly little changed on CocoaPods regarding how the project is built... Xcode 5.1.1?

@fabiopelosin
CocoaPods member

Closing because reported as fixed... if somebody encounters a case in which is still creating issues, please repot.

@rivera-ernesto

Anyway seems like it's the new default and suggested setting, so we'll have to "deal with it".

@fabiopelosin
CocoaPods member

:metal:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment