Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Feature request: provide the ability to prevent `pod install` from adding certain build phases #1744

Closed
paulyoung opened this Issue · 15 comments

4 participants

@paulyoung

My use case is described in this question on Stack Overflow.

Essentially I want to be able to satisfy dependencies during the development of a static library or framework, but not distribute them along with that library or framework.

I don't believe that this is currently possible via existing functionality or by using a workaround.

I think that this means providing the ability to do the following:

  • Not add libPods.a to the "Link binary with Libraries" build phase
  • Not add the "Copy Pods Resources" build phase

There may be other steps that I'm unaware of.

If someone could provide some guidance I'd be happy to work on this and create a pull request.

Thanks.

@fabiopelosin

At a glance I would tempted to say that your proposal doesn't passes the litmus test of being useful for the 80% of the users, although I don't understand your usage case completely. I would recommend to use the --no-integrate flag and perform any integration step that you are interested in manually (I think just setting the xcconfigs to your target).

@fabiopelosin

Closing until proof of interestingness is provided (feel free to continue the discussion – I do this to tame the will beast known as the issues list :smile:)

@paulyoung

Also, this seems to be relevant: #1250

@paulyoung

I would recommend to use the --no-integrate flag and perform any integration step that you are interested in manually (I think just setting the xcconfigs to your target).

I think I'd need to add both projects to a workspace but I'm not sure about other steps. I also want the build phase that checks the lockfile so I'd need to add that. It's not clear to me what I'd need to do the next time I run pod install or add a target.

I'm hesitant to do this since my manual steps could be incompatible with future version of CocoaPods.

I'm trying to eliminate performing things manually and am looking for a solution that will work as the project changes and the team grows.

@paulyoung

@irrationalfab - also, with my Podfile:

def import_pods
  pod 'Foo', :path => '.'
end

target :ios do
  platform :ios, '7.0'
  link_with 'libFooSDK'
  import_pods
end

target :osx do
  platform :osx, '10.9'
  link_with 'FooSDK'
  import_pods
end

when using the --no-integrate flag, I receive the following message: [!] It is necessary to specify the platform in the Podfile if not integrating.

@paulyoung

@irrationalfab - would it be correct to assume that if deps is specified (#1585) then the dependency ultimately won't be linked?

@paulyoung

To clarify, I was asking if it be correct to assume that if deps is specified then the dependencies of the provided podspec won't be linked.

@alloy
Owner

@kylef Had some ideas for a plugin that would be able to build such ‘distribution’ libraries (i.e. without including the deps). Maybe he can share his ideas and/or you can work together. For now I agree with @irrationalfab that it’s not something we need in the main tool.

@fabiopelosin

@paulyoung

For reference: http://stackoverflow.com/questions/17092822/building-a-static-library-with-cocoapods

As a suggestion: that link or a better explanation of your ultimate goal would have been helpful in the original ticket.

I'm hesitant to do this since my manual steps could be incompatible with future version of CocoaPods.

Good points, however as @alloy mentions it would me more appropriate to have a solution for a specific usage case. I think as well that this solution should be implemented as a plugin and only if later on is considered useful enough integrating it in the main tool should be considered.

[!] It is necessary to specify the platform in the Podfile if not integrating.

This is the implicit target messing around. We need to change to change the DSL to prevent this, in the meanwhile just specifying any platform at the top of the Podfile should be enough.

would it be correct to assume that if deps is specified (#1585) then the dependency ultimately won't be linked?

No that issue is about linking only the dependencies and not the Pod.

@kylef
Owner

@paulyoung I working towards a CocoaPod's plugin which would offer functionality to build an embedded framework or static library which includes a pod spec and could be used to offer a binary version of a CocoaPod.

Usage

You can use the command as follows:

$ pod spec embed PODNAME_OR_SPECFILE

It will generate a folder called "PODNAME.embeddedframework". For example, this might look like the following:

PSPDFKit.embeddedframework
├── PSPDFKit.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── PSPDFKit -> Versions/Current/PSPDFKit
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
│       ├── A
│       │   ├── Headers
│       │   │   ├── ..
│       │   ├── PSPDFKit
│       │   └── Resources
│       │       ├── ACKNOWLEDGEMENTS
│       │       ├── Info.plist
│       │       ├── LICENSE
│       │       ├── License.pdf
│       │       ├── PSPDFKit-nosqlite.xcconfig
│       │       ├── PSPDFKit.bundle
│       │       │   ├── ..
│       │       ├── PSPDFKit.xcconfig
│       │       └── VERSION
│       └── Current -> A
└── Resources
    ├── PSPDFKit-Acknowledgements -> ../PSPDFKit.framework/Resources/ACKNOWLEDGEMENTS
    ├── PSPDFKit-License -> ../PSPDFKit.framework/Resources/LICENSE
    ├── PSPDFKit-License.pdf -> ../PSPDFKit.framework/Resources/License.pdf
    ├── PSPDFKit-Version -> ../PSPDFKit.framework/Resources/VERSION
    ├── PSPDFKit-nosqlite.xcconfig -> ../PSPDFKit.framework/Resources/PSPDFKit-nosqlite.xcconfig
    ├── PSPDFKit.bundle -> ../PSPDFKit.framework/Resources/PSPDFKit.bundle
    └── PSPDFKit.xcconfig -> ../PSPDFKit.framework/Resources/PSPDFKit.xcconfig

26 directories, 801 files

It will also generate a Podspec for this generated embeddedframework, which would look something like (not sure how source would work):

Pod::Spec.new do |s|
  s.name         = "PSPDFKit"
  s.version      = "3.3.5"
  s.homepage     = "http://pspdfkit.com"
  s.license      = { :type => 'Commercial', :file => 'PSPDFKit.embeddedframework/PSPDFKit.framework/Resources/LICENSE' }
  s.author       = { "PSPDFKit GmbH" => "support@pspdfkit.com" }
  s.summary      = "The definitive framework for displaying and annotating PDFs in your iOS apps."

  s.description  = <<-DESC
                   The definitive framework for displaying and annotating PDFs in your iOS apps.
                   DESC
  s.screenshots  = "http://pspdfkit.com/images/frontpage/heroshot_pspdfkit_ipadmini.jpg", "http://pspdfkit.com/images/frontpage/heroshot_pspdfkit_iphone5.png"

  s.platform     = :ios, '6.0'
  s.source       = { :http => "https://customers.pspdfkit.com/download/3.3.5.zip" }

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

  s.library       = 'z', 'sqlite3', 'xml2'
  s.xcconfig      = { 'FRAMEWORK_SEARCH_PATHS' => '"$(PODS_ROOT)/PSPDFKit/**"',
                      'HEADER_SEARCH_PATHS' => '$(SDKROOT)/usr/include/libxml2' }
  s.frameworks    = 'QuartzCore', 'CoreText', 'CoreMedia', 'MediaPlayer', 'AVFoundation', 'ImageIO', 'MessageUI',
                    'CoreGraphics', 'Foundation', 'CFNetwork', 'MobileCoreServices', 'SystemConfiguration',
                    'AssetsLibrary', 'Security', 'UIKit', 'AudioToolbox', 'QuickLook', 'CoreTelephony'
  s.requires_arc = true
end

Optionally, providing the --full argument will package up all dependencies to go into the embedded framework. Otherwise it would expect the frameworks to be available when linking/at runtime.

@paulyoung

Thanks, everyone, for your input.

It appears that since I already have targets for a static library and framework set up, all I'd need to do is create a CocoaPods plugin that extends Pod::Installer::UserProjectIntegrator::TargetIntegrator and overrides the add_pods_library and add_copy_resources_script_phase methods, although these methods are marked as private.

@paulyoung

@irrationalfab - can I suggest updating the contributing guidelines to mention the 80% litmus test?

@fabiopelosin

@paulyoung sure sounds great! Please send a pull request as you might have a better understanding of how we could improve this part

@paulyoung

@alloy, @irrationalfab, @kylef - would any of you mind outlining how you think a plugin to achieve what I'm looking for might work?

pod install --no-link-with-libraries --no-copy-pods-resources

I took a look at doing this a few weeks back but I couldn't quite figure it out and would like to give it another go.

Some advice along the lines of, "subclass A and B and override methods X and Y", etc. would be great.

Thanks in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.