Hello Andrea,
I’ve tested the static build and use it in push demo [1] with a new certificate and the
UPS openshift instance (quickstarts created by Sebi). I’ve transformed xcodeproject not to
link to any cocopods artifacts. Then, I’ve used Method 1 described in raywenderlich blog
[2] to link to the built static lib.
It works well out of the box. I haven’t tested it on 64bits device yet.
+1 on using fwk as you said it simplifies the end user experience. But as jverkoeyen
stated it its the readme [3] instruction "Building a static iOS framework is a
pain…”, well, it requires more work ;)
In the meantime, we can use your static lib with headers file, are we going to store the
fat lib in the demo repo?
++
Corinne
[1]
This error is because of the CONFIGURATION_BUILD_DIR try
TARGET_BUILD_DIR instead
On 7 Apr,2014, at 11:20 , Erik Jan de Wit <edewit(a)redhat.com> wrote:
> I’ve tried to build with this script but it doesn’t work. I was also in the progress
of creating a script that would do exactly the same to release the push plugin and always
include the latest aerogear-push-ios-registation release as a binary
>
> This is the error I get:
>
>
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
-dynamic not specified the following flags are invalid: -ObjC
>
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
can't locate file for: -lPods
>
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
file: -lPods is not an object file (not allowed in a library)
> Command
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
failed with exit code 1
>
>
> On 7 Apr,2014, at 10:53 , Andrea Vibelli <avibelli(a)redhat.com> wrote:
>
>> Hi all,
>> for those who are not able or willing to use Cocoapods, it would be nice to
distribute a static binary library of aerogear-push-ios-registration.
>> In order to support multiple platforms without the need to create multiple
configurations or build products, I think that the best way would be to create a universal
binary (aka fat library) that contains the object code for both architectures (device +
simulator) and the public headers files.
>>
>> Going further, from the universal library it could be possible to create a
framework, that would bring everything together into one package (a directory with a known
structure). Packaging a library as a framework simplifies things for developers because it
not only provides a binary to link against but it includes all of the necessary header
files to reference as well.
>>
>> I have tried to create a script that builds a universal static library first and
then a framework (putting together some links [1],[2],[3],[4]), is anybody willing to help
to check it and test the built bits inside the cordova-push-plugin?
>>
>> You can find the script here:
https://github.com/vibe13/aerogear-push-ios-registration/blob/master/univ...
>>
>> The script should be placed inside the project root and run:
./universal_lib-framework_build.sh
>>
>> Thank you
>> Andrea
>>
>> [1]
http://www.meonbinary.com/2013/07/creating-universal-ios-framework
>> [2]
http://spin.atomicobject.com/2011/12/13/building-a-universal-framework-fo...
>> [3]
https://github.com/jverkoey/iOS-Framework
>> [4]
http://www.cocoanetics.com/2010/04/making-your-own-iphone-frameworks/
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev