Can't build KissXML/libxml_module in Xcode 8

[colinhumber]

Compiling a brand new project with the following Podfile seems to ignore the DDXML_LIBXML_MODULE_ENABLED flag and tries to run #import <libxml/tree.h> instead of the modules. This setup works as expected in Xcode 7. Presumably it has something to do with the libxml.modulemap, it the paths inside point to /Applications/Xcode.app, not Xcode-beta.app...

platform :ios, '9.0'

target 'KissXMLTest' do
  use_frameworks!
  pod 'KissXML/libxml_module'
end

[chrisballinger]

Ohhhhh yes. I'm definitely not happy about how Apple left developers to create their own modulemaps for libxml, CommonCrypto, sqlite, etc. We are also missing modulemaps for a bunch of other platforms like watch and tv.

SQLite.swift has a number of them here: https://github.com/stephencelis/SQLite.swift/blob/master/SQLite.swift.podspec#L35
https://github.com/stephencelis/SQLite.swift/tree/master/CocoaPods

I'm not sure how we could support both easily in the same podspec, but perhaps in the readme we could point people to a Xcode-beta branch? Oh yeah another issue is people running 10.12 and not Xcode-beta, and Xcode-beta and 10.11...

:(

[colinhumber]

What I'm a little confused about is why the #if DDXML_LIBXML_MODULE_ENABLED check is ignored. I can hack the modulemap to point to Xcode-beta.app, but this check always seems to return false, which forces the #import <libxml/tree.h> to run instead of importing the appropriate module.

The flag is property included in the OTHER_SWIFT_FLAGS and OTHER_CFLAGS.

[chrisballinger]

I'm wondering if a better route would be to remove all references to libxml from the public headers. It seems easy to fix in DDXMLNode without breaking backwards compatibility but NSString+DDXML might be trickier because the public API exposes xmlChar directly. Even though xmlChar is just a typedef for unsigned char, I don't see a great way to fix it without introducing tons of warnings into people's projects, or breaking things entirely.

[colinhumber]

Might be worth just keeping an eye on as Xcode betas keep coming out. I just installed beta 2, and it introduced more errors that weren't present before.

[chrisballinger]

Is there any way it's pulling in two modulemaps for both beta and non-beta? I guess if the ifdef isn't working it's not pulling in anything though..

[colinhumber]

I started tinkering with having a nested beta subspec under libxml_module, that references a second .modulemap that points to Xcode-beta.app.

  s.subspec 'libxml_module' do |ss|
    ss.subspec 'beta' do |beta|
      beta.preserve_path = 'libxml/module-beta.modulemap'
    end
 ...

and then

pod "KissXML/libxml_module/beta"

Still a WIP to see if I can get it working. I'm still wrapping my head around the modulemap stuff, so I don't even know if having a second file named something other than module.modulemap even works...

[chrisballinger]

I thiiink it needs to be named module.modulemap, so perhaps put it in a different folder. You also need to make sure that the modulemap folder path is included in the header search paths: https://github.com/robbiehanson/KissXML/blob/master/KissXML.podspec#L34

[colinhumber]

Ya, you're right. I pulled that and just tried changing the paths in module.modulemap to point to Xcode-beta.app and it's still causing issues. Seems like a lot of the issues are just due to the DDXML_LIBXML_MODULE_ENABLED being ignored. 😦

Gonna need to keep digging...

[chrisballinger]

Maybe Swift 3 changed how they expect preprocessor defines on the command line? Hopefully it's not deprecated...

[colinhumber]

I ran the converter and am using Swift 2.3, same issues. Definitely seems
like something changed with preprocessor defines in Xcode 8…

I just noticed in the release notes that there’s a new build setting for
Swift. Doesn’t fix the issue, but something to be aware of, at any rate.

“Active Compilation Conditions” is a new build setting for passing conditional compilation flags to the Swift compiler. Each element of the value of this setting passes to swiftc prefixed with "-D", in the same way the elements of “Preprocessor Macros” pass to clang with the same prefix. (22457329)

[colinhumber]

So, it definitely seems like the preprocessor define isn't being handled.

In DDXMLNode.h, I added the following at the top, just to see if the flag was defined, and sure enough, it's not.

#ifndef DDXML_LIBXML_MODULE_ENABLED
#error "UNDEFINED"
#endif

[chrisballinger]

Aha! That changelog entry is most likely the cause and possibly an Apple or CocoaPods bug. There is definitely funky stuff that happens when Swift imports Objective-C modules, and I bet that the flags aren't being passed around properly from Swift->ObjC.

I bet it works fine when imported into an Obj-C project (with modules).

[colinhumber]

😢 No joy... I'm trying to just build the KissXML framework directly now at it's still failing. Ugh... I'm sure it's gonna end up being one flag that is new or needs flipping to get this working...

[chrisballinger]

There's some discussion possibly related to this here: http://stackoverflow.com/questions/24003291/ifdef-replacement-in-swift-language

Try -D DDXML_LIBXML_MODULE_ENABLED instead of -DDDXML_LIBXML_MODULE_ENABLED

It seems that you also can't set it =1 so we might have to change the obj-c ifdef to be ifdef instead of if.

[colinhumber]

So... in order to get rid of the issues with the #if DDXML_LIBXML_MODULE_ENABLED check failing, in Xcode 8 I needed to add DDXML_LIBXML_MODULE_ENABLED=1 to the list of Preprocessor Macros, not the OTHER_CFLAGS. 😐 However, now it can't fine the actual modules.

The new compiler must have changed how SWIFT/OTHER_CFLAGS work.

[colinhumber]

I had KissXML setup as a local development pod, and the search paths don't pick up the module.modulemap in this config. I think I have a handle on this now. Gonna play around a bit and get this working tonight.

[chrisballinger]

You may be interested in my new branch that removes libxml from the public headers entirely:

https://github.com/robbiehanson/KissXML/tree/private_libxml

Seems like a nice way to work around the problem and hopefully doesn't break anything for people. :)

[colinhumber]

With DDXMLPrivate.h importing <libxml/tree.h>, it's throwing the same error as above in Xcode 8. Xcode 7 is still working as expected. 😞

Update: I think I have a workaround. Please hold...

[colinhumber]

Added a small fix to the podspec to fix this issue in PR #68. Tested a clean pod install in Xcode 8 with the private_libxml branch with the podspec changes and everything compiles!

Thanks a ton for all the help @chrisballinger! I owe you a beer. 😄

[chrisballinger]

Ya no problem! :)

Btw I used to use itunes_transporter_generator before I switched to Deliver. Even made an issue 3 years ago: https://github.com/colinhumber/issues/19

[colinhumber]

Awesome! Ya, that project died pretty quick after Deliver came out, and rightly so. Deliver is amazing!