cocoapods / cocoapods-packager Goto Github PK

On iOS this should generate an embedded framework, on OS X it can just generate an ordinary framework.

This should generate a podspec for consuming the generate framework too.

Example usage:

$ pod lib/spec package KFData
$ tree KFData.embeddedframework
KFData.embeddedframework
├── KFData.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── KFData -> Versions/Current/KFData
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
│       ├── A
│       │   ├── Headers
│       │   │   ├── ..
│       │   ├── KFData
│       │   └── Resources
│       │       ├── ACKNOWLEDGEMENTS
│       │       ├── Info.plist
│       │       ├── LICENSE
│       │       ├── KFData.bundle
│       │       │   ├── ..
│       │       ├── KFData.xcconfig
│       │       └── VERSION
│       └── Current -> A
└── Resources
    ├── KFData-Acknowledgements -> ../KFData.framework/Resources/ACKNOWLEDGEMENTS
    ├── KFData-License -> ../KFData.framework/Resources/LICENSE
    ├── KFData-Version -> ../KFData.framework/Resources/VERSION
    ├── KFData.bundle -> ../KFData.framework/Resources/KFData.bundle
    └── KFData.xcconfig -> ../KFData.framework/Resources/KFData.xcconfig

26 directories, 801 files

And the generated podspec:

Pod::Spec.new do |s|
  s.name         = "KFData"
  s.version      = "1.0.1"
  s.license      = { :type => 'BSD', :file => 'KFData.embeddedframework/KFData.framework/Resources/LICENSE' }
  s.author       = { "Kyle Fuller" => "[email protected]" }
  s.summary      = "The summary taken from the original podspec"

  s.platform     = :ios, '5.0'
  s.source       = { :http => "< INSERT HERE>" }

  s.preserve_paths      = 'KFData.embeddedframework/KFData.framework'
  s.public_header_files = 'KFData.embeddedframework/KFData.framework/Versions/A/Headers/*.h'
  s.resource            = 'KFData.embeddedframework/KFData.framework/Versions/A/Resources/KFData.bundle'
  s.vendored_frameworks = 'KFData.embeddedframework/KFData.framework'

  s.frameworks    = 'CoreData'
end

TODO list for this:

• Build static libraries for all platforms and architectures
• Fix CocoaPods/CocoaPods#1767 so that there are no issues with PodsDummy... classes
• Generate static framework
• Package resources
• Generate embedded framework

This rolls on from #7 and would be super simple considering this just chucks the arguments in a Podfile.

So, here's an example:

$ pod package Disclose
Disclose.framework has been built.

$ pod package --name=DiscloseSimple Disclose/List Disclose/Delete
DiscloseSimple.framework has been built from `Disclose/List`, and `Disclose/Delete`.

Generate a README.md in the output directory with generic integration instructions (and would comply with --no-pod option proposed in #23) because basically everybody writes up the same spiel about "you should use CocoaPods, but if you don't, here are the basic integration instructions"

Consider porting some of the structure from braintreeps/cocoapods-archive

Generated README's structure

• Basic information (name, author, summary)
• System/platform requirements
• Generic download/drag and drop integration instructions
• Custom Build Settings
• Custom options under Build Phases (libraries and frameworks)
• Instructions for including acknowledgements
• #import instructions
• License

That way, if a Podfile.lock is already in the directory, it isn't overwritten. The same goes for the podspec.

By default, the packager mangles class names, to avoid conflicts. As a user who depends on Pods which includes categories, one might also want a similar mangling to be applied to selectors provided by those categories. This is currently not done and cannot be achieved using the simple preprocessor based mangling that the packager uses.

pod package path/to/directory or pod package path/to/random/file both result in a stack trace.

For a directory:

Errno::EISDIR - Is a directory @ io_fread - [...]my-pod/
[...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-core-0.33.1/lib/cocoapods-core/specification.rb:491:in `read'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-core-0.33.1/lib/cocoapods-core/specification.rb:491:in `block in from_file'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-core-0.33.1/lib/cocoapods-core/specification.rb:491:in `open'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-core-0.33.1/lib/cocoapods-core/specification.rb:491:in `from_file'
[...].rvm/gems/ruby-2.1.1@my-pod/bundler/gems/cocoapods-packager-f121921d2165/lib/pod_utils.rb:44:in `spec_with_path'
[...].rvm/gems/ruby-2.1.1@my-pod/bundler/gems/cocoapods-packager-f121921d2165/lib/pod/command/package.rb:27:in `initialize'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/claide-0.6.1/lib/claide/command/parser.rb:24:in `new'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/claide-0.6.1/lib/claide/command/parser.rb:24:in `parse'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/claide-0.6.1/lib/claide/command/parser.rb:20:in `parse'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/claide-0.6.1/lib/claide/command.rb:288:in `parse'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-0.33.1/lib/cocoapods/command.rb:39:in `parse'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/claide-0.6.1/lib/claide/command.rb:276:in `run'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-0.33.1/lib/cocoapods/command.rb:48:in `run'
[...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-0.33.1/bin/pod:33:in `<top (required)>'
[...].rvm/gems/ruby-2.1.1@my-pod/bin/pod:23:in `load'
[...].rvm/gems/ruby-2.1.1@my-pod/bin/pod:23:in `<main>'
[...].rvm/gems/ruby-2.1.1@my-pod/bin/ruby_executable_hooks:15:in `eval'
[...].rvm/gems/ruby-2.1.1@my-pod/bin/ruby_executable_hooks:15:in `<main>'

For a file that is not a podspec:

➜  my-pod git:([email protected]) ✗ pod package ~/my-pod/CHANGELOG.md
[!] Unsupported specification format `.md`.
[...].rvm/gems/ruby-2.1.1@my-pod/gems/claide-0.6.1/lib/claide/command.rb:304:in `handle_exception': undefined method `verbose?' for nil:NilClass (NoMethodError)
        from [...].rvm/gems/ruby-2.1.1@my-pod/gems/claide-0.6.1/lib/claide/command.rb:284:in `rescue in run'
        from [...].rvm/gems/ruby-2.1.1@my-pod/gems/claide-0.6.1/lib/claide/command.rb:274:in `run'
        from [...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-0.33.1/lib/cocoapods/command.rb:48:in `run'
        from [...].rvm/gems/ruby-2.1.1@my-pod/gems/cocoapods-0.33.1/bin/pod:33:in `<top (required)>'
        from [...].rvm/gems/ruby-2.1.1@my-pod/bin/pod:23:in `load'
        from [...].rvm/gems/ruby-2.1.1@my-pod/bin/pod:23:in `<main>'
        from [...].rvm/gems/ruby-2.1.1@my-pod/bin/ruby_executable_hooks:15:in `eval'
        from [...].rvm/gems/ruby-2.1.1@my-pod/bin/ruby_executable_hooks:15:in `<main>'

I'd expect these cases to result in an error message with usage instructions.

As the symbol mangling relies on preprocessor defines, it cannot work with binary-only Pods. The user should be informed about this and the packaging should be aborted.

in RestKit since 0.21 in RestKit.podspec changed to:

# Add Core Data to the PCH if the Core Data subspec is imported. This enables conditional compilation to kick in.
  s.prefix_header_contents = <<-EOS
#ifdef COCOAPODS_POD_AVAILABLE_RestKit_CoreData
    #import <CoreData/CoreData.h>
#endif

and generate below in Pods-RestKit-prefix.pch

#import "Pods-environment.h"
#ifdef COCOAPODS_POD_AVAILABLE_RestKit_CoreData
    #import <CoreData/CoreData.h>
#endif

when pod install with target project, below code added to Pods-envrionmen.h

// CoreBeaconShop
#define COCOAPODS_POD_AVAILABLE_CoreBeaconShop

These mechanism make the Rest flexible to install with or without CoreData part. but when using with pod package, installed with target set to false, only empty Pods-envrionment.h generated, and the RestKit CoreData part code will not be compiled. Meanwhile in latest podspec, :git or :path do not supported on dependency, I can not replace with modified Restkit podspec, there is no way out.
The best way to solve the problem, or other similarity, I think is to make the Pods-envrionment.h generated as target project set.

Is it possible to customize the packaging of the new pod, such as changing the name? For example, a private pod named SemiHelloWorld and I want to package a framework named SemiHelloWorldStatic. Is there an easy way to do this in the parent's podspec?

Thanks for all the hard work on this project.

Eventually, we will want to be able to build dynamic frameworks using the packager.

The goal should remain that the dependencies are vendored with mangled symbols by default, so that the generated framework is suitable for easy distribution. As dynamic frameworks are more reasonable in terms of users providing transitive dependencies themselves, there could also be an option for producing leaving the dependencies out completely.

In general, dependencies need to be build as static libraries, so that they can be lipo'ed into the dynamic framework. Xcode will take care of public headers and resources for us and Swift Pods gives us a generated module map already.

This generated an invalid podspec for me which looked like the following:

s.source = {:git=>"https://github.com/cocodelabs/Disclose", :tag=><Pod::Version version=0.1.0>

I used something like this:

spec.source = { :git => 'https://github.com/cocodelabs/Disclose', :tag => spec.version }

Which is valid as far as CocoaPods is concerned. CocoaPods/Core@6af9a00

CocoaPods should be usable for companies that want to distribute binary builds (for the purpose of keeping the source private) of their pods directly, while still maintaining the dependency resolution flexibility we have now from raw source.

The packager should be able to package up just the source files specified in the podspec, without including other dependencies specified in the spec. In this manner, there will be no risk of duplicated symbols if other pods rely on the same dependencies.

There should also be a way for the packager to turn the 'source' podspec into a 'binary' podspec that can be pushed to trunk.

When I require 'builder', Ruby loads the builder.rb file from cocoapods-packager instead of loading the builder gem. The cocoapods-packager builder.rb should be loaded via a namespace directory to avoid this conflict e.g. require "cocoapods-packager/builder"

It is a general convention that gems have a folder within the lib directory to house files that might cause conflicts with other parts of the system.

http://weblog.rubyonrails.org/2009/9/1/gem-packaging-best-practices/

Could we re-organize the lib directory to avoid conflicts with other gems?

Thanks

Carthage plans to add support for binaries (see Carthage/Carthage#257) and this seems like the best way to provide compatibility for libraries which do not want to manage superfluous Xcode projects.

I installed cocoapods-packager 1.1.0.

$ gem install cocoapods-packager
Successfully installed cocoapods-packager-1.1.0

Running a simple command like

$ pod package CocoaLumberjack
[!] Unable to find a podspec with path or name.

Despite the docs saying

--spec-sources=private,https://github.com/CocoaPods/Specs.git   The sources to
                                                                    pull dependant
                                                                    pods from
                                                                    (defaults to
                                                                    https://github.com/CocoaPods/Specs.git)

Am I doing something wrong, or does the documentation need to be updated? Thanks.

Hi @kylef
Thanks for working on this, this looks great. I'd love to support you, but could you please provide a bit more information about the setup and how to get this to run?

I did the following already:
Build the gem: 'gem build cocoapods-packager.gemspec'
Install it: 'sudo gem install cocoapods-packager'

What's next? What am I missing?
Thanks

The v1.0.1 tag is incompatible with the current release version of CocoaPods. If you update to the CocoaPods pre-release to fix that, then the packager can’t bundle your private spec repos because it only looks for pods from the master specs repo.

I'm getting a fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: can't open input file: Pods/build/package.a (No such file or directory)

The framework is still being created, but it doesn't include the static library.
I'm getting error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: no files specified prior that. Is it probably related to Xcode command line tools? I'm using OSX 10.10

If vendored_libraries or vendored_frameworks are specified in the podspec, they should be compiled into the generated static library just like source files.

I am trying to build a package a library using packager but the project I add it to will not build due to errors that look like:

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_PodMyLibrary_CABasicAnimation", referenced from:
...

Correct me if I am wrong but does this mean that CABasicAnimation has been mangled? Why is this the case and is there something I am missing?

Would like to include two frameworks via cocoapods, but one is dependent on the other. pod package of both and adding them to the project yields a duplicate symbol error. Can't figure out how to access subspecs' symbols from one framework. Would like to be able to include/add the highest level framework and access it's dependencies to avoid this situation.

Cheers

In addition to the frameworks described in #1, this plugin should also be able to just build a static library for all relevant architectures. I am thinking of a switch like --library-only only or something like that.

Other possibility: build a library by default and have a --framework switch to build the framework.

Opinions?

I simply cannot get the generated frameworks to work when included from an app that uses Cocoapods. Maybe I'm doing something wrong or cocoapods-packager is broken with the latest CocoaPods or Xcode?

When trying to build the app consuming the static lib (framework) included through cocoa pods i get the following linker error:

duplicate symbol _OBJC_METACLASS_$_PodsDummy_Pods_LibraryDemo in:
    /tmp/packager-demo/LibraryConsumer/build/Products/Debug-iphonesimulator/libPods-LibraryDemo.a(Pods-LibraryDemo-dummy.o)
    /private/tmp/packager-demo/Library/LibraryDemo-1.0.0/ios/LibraryDemo.framework/LibraryDemo(Pods-LibraryDemo-dummy.o)
duplicate symbol _OBJC_CLASS_$_PodsDummy_Pods_LibraryDemo in:
    /tmp/packager-demo/LibraryConsumer/build/Products/Debug-iphonesimulator/libPods-LibraryDemo.a(Pods-LibraryDemo-dummy.o)
    /private/tmp/packager-demo/Library/LibraryDemo-1.0.0/ios/LibraryDemo.framework/LibraryDemo(Pods-LibraryDemo-dummy.o)
ld: 2 duplicate symbols for architecture x86_64

I have created a sample project to make it easy to reproduce the issue. To reproduce:

Clone the repo containing the library (to be a static lib pod) and the repo containing the example app to consume the static library pod:

$ mkdir cocoapods-packager-issue 
$ cd cocoapods-packager-issue 
$ git clone [email protected]:olegam/LibraryDemo.git
$ git clone [email protected]:olegam/LibraryConsumerDemo.git

Build the static lib/framework:

$ cd LibraryDemo
$ pod package LibraryDemo.podspec --force

Install pods for consuming app project:

$ cd ../LibraryConsumerDemo 
$ pod install
$ open LibraryConsumer.xcworkspace/

Trying to compile the app by opening the generated workspace file in Xcode and hitting CMD-R gives me the linker error shown above.

What is wrong here?

Do we generate two sets of artifacts or will a platform argument be required?

I'm testing the basics of --subspec packaging.

$ pod package AFNetworking.podspec AFNetworking --subspecs
[!] Unknown option: `--subspecs`
Did you mean: --subspecs

or...

$ pod package AFNetworking.podspec AFNetworking --subspecs Reachability
[!] Unknown option: `--subspecs`
Did you mean: --subspecs

How is this supposed to be used?

When building with --library flag I got only *.a and no header files. Also podspec looks just like when building framework

https://github.com/CocoaPods/cocoapods-packager/blob/master/lib/spec_builder.rb.

I've built a framework using packager from my podspec. There were no errors in output. But when I try to use built framework in dependant project xcode says that all public simbols from that framework I use are not defined for selected architecture.
The same problem with static lib.

I have command line tools Xcode 6.1 (6A1052c)

packager output:

Generating Pods project
Building framework
Mangling symbols
Building mangled framework
cp: Pods/***/LICENSE: No such file or directory

In nm out I see symbols for dependencies I use, but don't see any of my own symbols
(possible duplicate #47)

Xcode 6 does not build it by default anymore, see http://wp.me/p2HLdW-2qu

At the moment, only headers in the root of the public headers directory of the main Pod are copied.

I'm not sure why I'd want to mangle my framework. We should provide an option not to (and I don't see why this wouldn't be the default).

$ pod package Disclose.podspec
Building framework
Mangling symbols
Building mangled framework

I ran into an into issue where symbols were missing from my packaged pod.

I tracked it down to xcodebuild failing (https://github.com/CocoaPods/cocoapods-packager/blob/master/lib/cocoapods-packager/builder.rb#L149). However, the pod package command appeared as though it ran successfully. It would be great if the return code of xcodebuild is checked for success, and a way to see the xcodebuild output when a failure occurs.

Their repo is over here https://github.com/braintreeps/cocoapods-archive.

Let's discuss what's it doing what packager isn't and how the two can fit together.

If a Pod subclasses a class from a dependency, its header will be required for further usage. Currently, the packager cannot provide that.

As a solution, the packager should be able to create frameworks stubs, similar to those that Apple ships for the ARM frameworks in the iOS SDK.

A workaround is also packaging the dependency and linking any application against both.

Can be verified by packaging ARAnalytics

I'm trying to avoid committing to Git prior to building a .framework using CocoaPods packager for local testing by setting s.source = { :path => <path to source folder> } however I get the following error:

$ pod package PathSpecTest.podspec
Analyzing dependencies
Fetching podspec for `PathSpecTest` from `PathSpecTest.podspec`
Downloading dependencies
Installing PathSpecTest (0.1.0)

[!] Error installing PathSpecTest
[!] Attempt to read non existent folder `/private/var/folders/lt/1cy1pl9j13q2tmv_2bc538pr0000gn/T/cocoapods-pvo5xiq5/Pods/PathSpecTest`.

I've create a sample here: https://github.com/smistry-toushay/cocoapods-packager-path-spec-test

The value for path in the podspec needs to be replaced with where the sample repo is cloned on your Mac.

cocoapods-packager is a huge help when automating a release process aimed at integrators who do not use CocoaPods. A --no-pod option would be a big help in that the generated artifacts would be 100% ready for distribution.

• Accept --no-pod argument
• Do not generate a .podspec
• Generate an xcconfig file
• Insert a comment containing the Pod's name, author and version in a comment on top of each header file

There is a design flaw in CoreVideo.h that makes it really hard to build a framework with Xcode 6 and deploy it on apps that are still being built with Xcode 5. Details on this issues here and here.

The only way around this problem would be, according to people familiar with the matter, is to build the framework setting "Link Frameworks Automatically" set to no, which is currently impossible to do using Packager (amazing tool, I can't stress that enough).

I have set up sample repos that reproduce this issue for both a podspec called clever-framework and the Integrating app. In order to repo the issue, cd into the clever-framework and pod package it using Xcode 6. Then open the IntegratingApp.xcodeproj using Xcode 5, drop the framework you just compiled, try to archive the app and you'll see that if fails with the following linker error.

ld: framework not found Metal for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Where did Metal come you ask? See, AFNetworking needs CoreGraphics, which brings Metal into the picture. Don't believe me? Do a otool -arch armv7 -fl clever-framework to the framework's binary, you'll see this:

Load command 9
     cmd LC_LINKER_OPTION
 cmdsize 32
   count 2
  string #1 -framework
  string #2 Metal

This bug is in reality a bad Framework design for Apple and we can work around it only setting the "Link Frameworks Automatically" to NO so the linker doesn't bring more frameworks than it should to the binary.

Thanks for hearing me out

PS: I manually added the compiled clever-framework.framework into the IntegratingApp repo and xcodeproj, so you can see this easily without bothering to compile the other repo.

I wanted to run the minimal test so I followed the directions here http://guides.cocoapods.org/making/using-pod-lib-create.html (pod named SemiFakeKit), added one class with a "hello world" method, and pushed the repo to a private pod repo. I can use the SemiFakeKit pod in a Podspec and it's simple class works as advertised.

However, the packaging dies prematurely:

$ pod package SemiFakeKit.podspec --verbose --force
  Preparing

Analyzing dependencies

Inspecting targets to integrate

Fetching external sources
-> Fetching podspec for `SemiFakeKit` from `SemiFakeKit.podspec`

Resolving dependencies of
Resolving dependencies for target `Pods' (iOS 7.0)
  - SemiFakeKit (from `SemiFakeKit.podspec`)

Comparing resolved specification to the sandbox manifest
  A SemiFakeKit

Downloading dependencies

-> Installing SemiFakeKit (0.0.4)
 > Git download
 > Git download
     $ /usr/bin/git clone [email protected]:semireg/SemiFakeKit.git /private/var/folders/f8/4z2ghh055b550yvtft4710mw0000gn/T/cocoapods-w4ty6xbt/Pods/SemiFakeKit
     --single-branch --depth 1 --branch 0.0.4
     Cloning into '/private/var/folders/f8/4z2ghh055b550yvtft4710mw0000gn/T/cocoapods-w4ty6xbt/Pods/SemiFakeKit'...
     Note: checking out '7dcee1a8eb01cae8fc407911a72eb4652db89c6e'.

     You are in 'detached HEAD' state. You can look around, make experimental
     changes and commit them, and you can discard any commits you make in this
     state without impacting any branches by performing another checkout.

     If you want to create a new branch to retain commits you create, you may
     do so (now or later) by using -b with the checkout command again. Example:

       git checkout -b new_branch_name

  - Running pre install hooks

Generating Pods project
  - Creating Pods project
  - Adding source files to Pods project
  - Adding frameworks to Pods project
  - Adding libraries to Pods project
  - Adding resources to Pods project
  - Linking headers
  - Installing targets
    - Installing target `Pods-SemiFakeKit` iOS 7.0
    - Installing target `Pods` iOS 7.0
  - Running post install hooks
  - Writing Xcode project file to `Pods/Pods.xcodeproj`
  - Writing Lockfile in `Podfile.lock`
  - Writing Manifest in `Pods/Manifest.lock`
Building framework
usage: mv [-f | -i | -n] [-v] source target
       mv [-f | -i | -n] [-v] source ... directory

As an aside, I have cloned AFNetworking and verified that "pod package" works on that podspec.

As one should only ship binaries for release versions, there is no need to operate on a local podspec and it only complicates things because the optionally generated podspec will name clash with the source one.

Currently the packager only takes a single podspec, but it would be nice to be able specify a Podfile, if a user chooses to only want integrate binary products.

I think this could internally work the same in both scenarios, where you either use the specified Podfile or dynamically generate one that has the specified podspec as its dependency. Whether or not this makes things simpler or more complex is unknown to me right now.

• Consider porting some of the copy from https://github.com/braintreeps/cocoapods-archive/blob/master/README.md
• Consider a demo gif/video

Currently, Pods are downloaded over the network which makes the suite take unnecessarily long and also fail often on Travis.

Somewhere along the line in iteration toward 1.0.0 support the resource bundles support was broken. When I package my project as an embedded framework the Resources directory is being created but the bundle is not populated