Add ability to build pod as a framework #50

Merged
merged 1 commit into from Jun 2, 2016

Conversation

Projects
None yet
2 participants
@lrossi
Contributor

lrossi commented Jun 2, 2016

TL;DR

With the final version of CocoaPods 1.0.0 out, I made another attempt and was able to add support for use_frameworks! without the need for introducing an additional subspec. I now recommend merging this PR over my previous one. However, I’m leaving the old PR open as well until the whole discussion on this topic is closed.

The nitty-gritty

I started out as in the previous PR (#44), thus since a straight build of the current pod with use_frameworks! leads to:

01

I added

s.pod_target_xcconfig   = { 'USER_HEADER_SEARCH_PATHS' => '${PODS_ROOT}/libxlsxwriter/include’ }

in the podspec.

Then a new problem arose:

02

In my previous PR, I solved this error by moving the xlsxwriter.h header inside of the xlsxwriter directory. However, what I had missed out is that it is possible to specify a custom module map file in the podspec. According to the Clang documentation, a module map

describes how a collection of existing headers maps on to the (logical) structure of a module.

Taking inspiration from the module map file that is usually generated by CocoaPods, I wrote a (slightly) custom one as follows:

framework module xlsxwriter {
  umbrella header "libxlsxwriter-umbrella.h"
  header "../xlsxwriter.h"

  export *
  module * { export * }
}

The second line inside the block fixes the compilation error. Hooray!

Oh wait, we’re not done yet

A new compilation error arose since the xlsxwriter framework is now missing the umbrella header, because CocoaPods doesn’t automacally generate it when specifying a custom module map file. Actually, this is not a bug but a feature. I then took the umbrella header previously generated by CocoaPods and manually added it to the repo. Since I didn’t want to pollute the include directory that is shared with other platforms, I created a new cocoapods directory with the module map and umbrella header files inside and added these lines to the podspec:

  s.prepare_command       = <<-CMD
                            cp cocoapods/libxlsxwriter-umbrella.h include/xlsxwriter/libxlsxwriter-umbrella.h
                          CMD

The bottom line

The obvious disadvantage of this solution is that whenever a new header file is added to the project, we need to remember to manually include it in the umbrella header. However, I still tend to favor this solution over my previous one since (1) it seems cleaner and (2) the pod can now be added to a project with a simple

pod 'libxlsxwriter'

in the Podfile, regardless of whether the use_frameworks! directive is specified or not.

What do you think?

P.S. If you want to quickly try it out, I made another branch in my example repo that uses this PR to import the pod.

@jmcnamara

This comment has been minimized.

Show comment
Hide comment
@jmcnamara

jmcnamara Jun 2, 2016

Owner

Hi Ludovico,

Thanks for that, and the very detailed breakdown. The change looks very clean.

I'll do a small bit of testing and merge it later.

The obvious disadvantage of this solution is that whenever a new header file is added to the project, we need to remember to manually include it in the umbrella header.

That isn't a problem. I'll build something into the release testing to make sure that the file is updated automatically.

Thanks,

John

Owner

jmcnamara commented Jun 2, 2016

Hi Ludovico,

Thanks for that, and the very detailed breakdown. The change looks very clean.

I'll do a small bit of testing and merge it later.

The obvious disadvantage of this solution is that whenever a new header file is added to the project, we need to remember to manually include it in the umbrella header.

That isn't a problem. I'll build something into the release testing to make sure that the file is updated automatically.

Thanks,

John

@jmcnamara jmcnamara merged commit 4f5b59e into jmcnamara:master Jun 2, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@jmcnamara

This comment has been minimized.

Show comment
Hide comment
@jmcnamara

jmcnamara Jun 3, 2016

Owner

Hi Ludovico,

I pushed version 0.3.7 with these changes. I also updated to pod version 1.0.1 locally.

However, I had to override the validation to get it to upload. I get a code signing error during linting:

$ pod spec lint libxlsxwriter.podspec --verbose

...

Touch /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework
    cd /var/folders/_s/_v0xr0hj2rx4l6pkbwx7l6pc0000gn/T/CocoaPods/Lint/Pods
    /usr/bin/touch -c /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework

CodeSign /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework/Versions/A
    cd /var/folders/_s/_v0xr0hj2rx4l6pkbwx7l6pc0000gn/T/CocoaPods/Lint/Pods
    export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate

Signing Identity:     "-"

    /usr/bin/codesign --force --sign - --timestamp=none /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework/Versions/A
/Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework/Versions/A: code object is not signed at all
In subcomponent: /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework/Versions/A/xlsxwriter.h
Command /usr/bin/codesign failed with exit code 1

** BUILD FAILED **

Could you:

  • Let me know if the uploaded cocoapod is okay.
  • If you see a similar error when you run the above command.

Thanks,

John

Owner

jmcnamara commented Jun 3, 2016

Hi Ludovico,

I pushed version 0.3.7 with these changes. I also updated to pod version 1.0.1 locally.

However, I had to override the validation to get it to upload. I get a code signing error during linting:

$ pod spec lint libxlsxwriter.podspec --verbose

...

Touch /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework
    cd /var/folders/_s/_v0xr0hj2rx4l6pkbwx7l6pc0000gn/T/CocoaPods/Lint/Pods
    /usr/bin/touch -c /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework

CodeSign /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework/Versions/A
    cd /var/folders/_s/_v0xr0hj2rx4l6pkbwx7l6pc0000gn/T/CocoaPods/Lint/Pods
    export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate

Signing Identity:     "-"

    /usr/bin/codesign --force --sign - --timestamp=none /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework/Versions/A
/Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework/Versions/A: code object is not signed at all
In subcomponent: /Users/John/Library/Developer/Xcode/DerivedData/App-hjpeheiavxbwlrdfvwejjhewameh/Build/Products/Release/libxlsxwriter/xlsxwriter.framework/Versions/A/xlsxwriter.h
Command /usr/bin/codesign failed with exit code 1

** BUILD FAILED **

Could you:

  • Let me know if the uploaded cocoapod is okay.
  • If you see a similar error when you run the above command.

Thanks,

John

@jmcnamara

This comment has been minimized.

Show comment
Hide comment
@jmcnamara

jmcnamara Jun 3, 2016

Owner

P.S. I'm not sure if the issue is down to to new spec file or the new pod. The pod command doesn't work with older versions of the spec file now either, but for different reasons.

Owner

jmcnamara commented Jun 3, 2016

P.S. I'm not sure if the issue is down to to new spec file or the new pod. The pod command doesn't work with older versions of the spec file now either, but for different reasons.

@lrossi

This comment has been minimized.

Show comment
Hide comment
@lrossi

lrossi Jun 3, 2016

Contributor

Thanks, I'll look at it ASAP

Contributor

lrossi commented Jun 3, 2016

Thanks, I'll look at it ASAP

@lrossi

This comment has been minimized.

Show comment
Hide comment
@lrossi

lrossi Jun 3, 2016

Contributor

Hi John,

Let me know if the uploaded cocoapod is okay.

Yes.

If you see a similar error when you run the above command.

Yes.

The problem seems to be related with the code signing phase being strictly required when building as a framework. The error should not arise in a real-world case, since the app linking to xlsxwriter must be code signed by itself in order to run on a physical iOS device (for instance, my examples are properly running on an iOS device with the updated pod).

As a workaround, running:

$ pod spec lint libxlsxwriter.podspec --use-libraries --verbose

seems to do the trick, since it builds the pod as a static library instead of building it as a framework.

According to the related issues that have been successfully closed in the CocoaPods repo it seems linting should now work even when building as a framework, so I'm not yet sure why it isn't working in our case. I may guess that, since the pod doesn't include any Xcode project file, the building command launched by CocoaPods doesn't know which identity to use for code signing... But this is pure late-Friday-evening speculation :) I'll take a more in-depth look at it to see if there is something we can do on our end to fix the problem. By the way, the linting issue should not harm the users of the pod.

Best,
Ludovico

Contributor

lrossi commented Jun 3, 2016

Hi John,

Let me know if the uploaded cocoapod is okay.

Yes.

If you see a similar error when you run the above command.

Yes.

The problem seems to be related with the code signing phase being strictly required when building as a framework. The error should not arise in a real-world case, since the app linking to xlsxwriter must be code signed by itself in order to run on a physical iOS device (for instance, my examples are properly running on an iOS device with the updated pod).

As a workaround, running:

$ pod spec lint libxlsxwriter.podspec --use-libraries --verbose

seems to do the trick, since it builds the pod as a static library instead of building it as a framework.

According to the related issues that have been successfully closed in the CocoaPods repo it seems linting should now work even when building as a framework, so I'm not yet sure why it isn't working in our case. I may guess that, since the pod doesn't include any Xcode project file, the building command launched by CocoaPods doesn't know which identity to use for code signing... But this is pure late-Friday-evening speculation :) I'll take a more in-depth look at it to see if there is something we can do on our end to fix the problem. By the way, the linting issue should not harm the users of the pod.

Best,
Ludovico

@jmcnamara

This comment has been minimized.

Show comment
Hide comment
@jmcnamara

jmcnamara Jun 4, 2016

Owner

Thanks. Good to know that the pod works.

And the workaround works for me to so that is probably sufficient. Enjoy the weekend and don't worry about it.

Owner

jmcnamara commented Jun 4, 2016

Thanks. Good to know that the pod works.

And the workaround works for me to so that is probably sufficient. Enjoy the weekend and don't worry about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment