builds dynamic framworks

[flovilmart]

I have a 'workaround' here to build dynamic frameworks just based on xconfigs, as I needed dynamic frameworks for a swift framework.

This producing the frameworks in build/ios through a shell script (not integrated with the rake bundle).

How do you think you could support that? In the future I will only require dylibs in the project I'm working on.

[nlutsenko]

@flovilmart, is there a specific reason why you need a dynamic framework for Swift framework?
One of the things that I would recommend that would probably unblock you is using "CocoaPods", as it already does the deployment via static/dynamic frameworks.

Will review and report few things on the code here in the meantime. I agree that this is a good idea in general, also would make us compatible with Carthage.

[nlutsenko]

Code review:

• We already have configurations built-in for most things, so you likely not need to recreate the new ones from scratch, but rather import existing ones and address few options that are explicitly set for dynamic
• Copyrights in all the headers should remain the same aka -> under Parse with BSD license
• Bash file that you put for building/deploying looks good, but if we want to ship this - we probably should simply duplicate one of the configurations in Rakefile and build using that

Overall, I would suggest taking a look at BoltsFramework/Bolts-ObjC#168 which was contributed recently to Bolts.framework. That one has the same feature built, but for Bolts.framework. You can base the implementation here off of that one.

[flovilmart]

I'm building ParseZero, that allows dump from a ParseApp to be preloaded in the app for a great first launch experience, even offline.It leverages the localDatastore and pins.This framework is in swift and meant to be distributed via Carthage.Mind that Parse is not initialized in that framework, but in the host app.Initially I was using the static lib framework and all was fine, even with the Unit Tests.When integrating in an app, I started having duplicate symbols problems as Parse (and Bolts) would be linked statically twice.Also because the symbols are different the Parse in the host app and the ParseZero framework would be different and uninitialized in the Framework.
Maybe there is a workaround, but Mach-O static is not supported with Swift frameworks.
Also, the dylib support would break iOS7 compatibility. Besides that, I don't see any reason not to start packaging it that way.
I also have in WIP a whole ParseToolkit repo to hole the whole Parse suite and build for Carthage distribution.

Envoyé à partir d'Outlook

_____________________________

From: Nikita Lutsenko notifications@github.com
Sent: mardi, novembre 24, 2015 7:11 PM
Subject: Re: [Parse-SDK-iOS-OSX] builds dynamic framworks (#600)
To: ParsePlatform/Parse-SDK-iOS-OSX parse-sdk-ios-osx@noreply.github.com
Cc: Florent Vilmart vfloz@me.com

@flovilmart, is there a specific reason why you need a dynamic framework for Swift framework?
One of the things that I would recommend that would probably unblock you is using "CocoaPods", as it already does the deployment via static/dynamic frameworks.

Will review and report few things on the code here in the meantime. I agree that this is a good idea in general, also would make us compatible with Carthage.

—
Reply to this email directly or view it on GitHub.

[nlutsenko]

That's actually the main reason why we don't ship only dynamic framework for iOS - we want to be explicitly compatible with iOS 7.
ParseZero and ParseToolkit sound like an amazing idea!

One of 2 things for shipping this here:

• I can guide you through the whole process on how to make the dynamic framework happen in Parse SDK
• Or we can build this in ourselves with your help :)

Let me know which path is easier and makes more sense for you.

[flovilmart]

As for the review, thanks for the tips :)

[flovilmart]

I guess I'll be able to manage with the effort that has been made on Bolts already.

[flovilmart]

Also in the Bolts projects, I really don't like the Target duplication that occurs because of the dynamic Scheme.
That is really problematic when a new class is added, one has to remember to add it to all targets.
If you don't mind, I'd propose an alternative solution

[nlutsenko]

Sure, that sounds good.
Keep in mind that we have 4 targets right now (iOS/OSX/tvOS/watchOS), and it is pretty manageable, so not big of a problem. I agree that it's ugly and adds extra cognitive overhead, but it is ok so far.

[flovilmart]

Should I pursue that route?

[nlutsenko]

Haha! Yeah, that works! Awesome find!

[flovilmart]

I'm not sure about setting the destinations from the rakefile, but if that works, that is way cleaner :)

[nlutsenko]

One thing - I wonder what happens with Configurations here, I mean Debug/Release...
Will it pass them forward to another target?

This is implicit and crazy, but I guess it works.

[flovilmart]

I'll check it out as we need at least to set a different -destination for the universal framework

[flovilmart]

Some parameters can be forwarded like -configuration others should be in the environment (like -destination).

[facebook-github-bot]

@flovilmart updated the pull request.

[facebook-github-bot]

@flovilmart updated the pull request.

[facebook-github-bot]

@flovilmart updated the pull request.

[facebook-github-bot]

@flovilmart updated the pull request.

[facebook-github-bot]

@flovilmart updated the pull request.

[flovilmart]

The shared configuration particularly the iOS breaks stuff as it forces the SDKROOT to iphoneos. I've just played with it and don't seem to have any clean workaround

[facebook-github-bot]

@flovilmart updated the pull request.

[facebook-github-bot]

@flovilmart updated the pull request.

[facebook-github-bot]

@flovilmart updated the pull request.

[flovilmart]

@nlutsenko btw, the toolchain is ready http://github.com/flovilmart/ParseToolchain

[facebook-github-bot]

@flovilmart updated the pull request.

[facebook-github-bot]

@flovilmart updated the pull request.

[nlutsenko]

@flovilmart Quick question on top of this:
If you use the shared configuration (as you mentioned it resets the SDKROOT), but specify sdk=iphoneos or sdk=iphonesimulator in xcodebuild arguments, will that work?

[flovilmart]

The override of the SDKROOT is because the Parse-iOS-Dynamic is a macos target and it needs to be overridden by default to an iphone SDKROOT (iphoneos or iphonesimulator)
passing the sdk argument is caught by the custom build script and forwarded so it works. Actually you can see that the build script forwards the SDKROOT from the one passed from the xcodebuild

-xcconfig Configurations/Parse-iOS-Dynamic.xcconfig -workspace Parse.xcworkspace -scheme Parse-iOS -configuration $(CONFIGURATION) -sdk $SDKROOT CONFIGURATION_BUILD_DIR=$(CONFIGURATION_BUILD_DIR) $(ACTION)

the $SDKROOT variable is the one passed when invoking:

xcodebuild -scheme Parse-iOS-Dynamic -sdk iphoneos | iphonesimulator

[nlutsenko]

And I am confused... why is it a macos target?

[flovilmart]

Xcode defines it that way.
The custom build target is a macosx target that will execute a script.
In the case of the Bolts-iOS target, you run a custom script that builds the framework, therefore you don't really care about the build settings of that target, but still, you force SDKROOT = iphoneos.

In the case of our Parse-iOS-Dynamic, we need to override those as well. The Parse-iOS-Dynamic.xcconfig is use to define the build settings for the target as well as the build settings for the Parse-iOS target.

That can be confusing.

[nlutsenko]

From what I understood:
The settings from Parse-iOS-Dynamic target are used to infer the settings for the Bolts dynamic target?

Here is the confusing part:

• Bolts-iOS-Dynamic - since it simply invokes a build script that is custom, why do we need to pass all these settings? We have Bolts-iOS that actually builds the framework for both iphoneos and iphonesimulator
• Parse-iOS-Dynamic - it should be purely used to define build settings for the target that builds a dynamic Parse.framework.

Not sure about the underlying difference, but iOS supports dynamic framework targets since Xcode 6 (I think the product type is the same as with macos, you are right).

Let's start from the beginning:
If you import iOS.xcconfig from xctoolchain, and remove most of the settings that are defined in Parse-iOS-Dynamic.xcconfig, what is the problem that you are experiencing? Let's try to fix that and remove duplicate and unrequired configurations as much as possible.

[flovilmart]

I've spent hours already trying to integrate with iOS.xcconfig and it breaks the build.
When adding #include "Shared/Platform/iOS.xcconfig" to Parse-iOS-Dynamic.xcconfig

$ rake build:ios_dynamic

** BUILD SUCCEEDED **

fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: /Users/florent/src/Parse-SDK-iOS-OSX/build/Release-ios-iphoneos/Parse.framework/Parse and /Users/florent/src/Parse-SDK-iOS-OSX/build/Release-ios-iphonesimulator/Parse.framework/Parse have the same architectures (armv7) and can't be in the same fat output file
Failed to lipo iOS framework.

[facebook-github-bot]

@flovilmart updated the pull request.

[flovilmart]

@nlutsenko Check in the last commit, I managed to do some things a bit cleaner, Configurations/Framework-iOS-Dynamic.xcconfig should probably go to the toolchain submodule. What do you think?

[facebook-github-bot]

@flovilmart updated the pull request.

[flovilmart]

@nlutsenko I just rebased and fixed a stupid typo in a file name

[nlutsenko]

Superseeded by #717