Подтвердить что ты не робот

Настройка Cocoapods с существующей статической библиотекой и iOS-приложением

У меня возникли проблемы с правильной компиляцией моего рабочего пространства с Cocoapods. В рабочей области есть 3 проекта, каждый из которых имеет свою собственную цель:

  • libPods - статическая библиотека Cocoapods со всеми внешними зависимостями
  • libCommon - моя статическая библиотека, где я храню весь свой общий код (базовые контроллеры, сетевой код, общий пользовательский интерфейс и т.д.)
  • myApp - приложение My iOS

Оба libCommon и myApp требуют внешних зависимостей от libPods. Первоначально я думал, что он будет работать следующим образом:

  • libPods строит
  • libCommon ссылки на libPods и сборки
  • ссылки myApp с libCommon и сборки

В этом случае libCommon "владеет" контейнерами, а затем myApp просто связывается с libCommon, как будто я всегда делал pre-Cocoapods... но, по-видимому, статические библиотеки не любят быть связанными со статическими библиотеками (я получил куча динамических ошибок библиотеки). Я где-то читал о проблеме github, вместо этого мне нужно было создавать libPods и libCommon, а затем myApp должен был ссылаться на обе библиотеки. Прямо сейчас мой подкайл выглядит примерно так:

workspace 'MyApp.xcworkspace'
platform :ios, '5.0'

link_with ['Common', 'MyApp']

target 'MyApp' do
  xcodeproj 'MyApp.xcodeproj'

  pod 'AFNetworking',               '1.1.0'
  pod 'TTTAttributedLabel',         '1.6.0'
  pod 'JSONKit',                    '1.5pre'
  pod 'Reachability',               '3.1.0'
end

При этой настройке myApp владеет всеми модулями, а затем в настройках сборки libCommon я указываю путь к заголовкам контейнера. Это создает ОК, пока я не попытаюсь использовать один из классов в libCommon. Как только я это сделаю, я получаю одну из этих ошибок _OBJC_CLASS_$_Blah (которая говорит мне, что, хотя заголовки доступны, они все еще не связаны должным образом). Когда я пытаюсь вручную связать libCommon в "Build Phases", я получаю кучу повторяющихся ошибок символов (что оставляет мне полагать, что оно уже связано?). Что за черт?

Как правильно это сделать и как должен выглядеть мой podfile?

4b9b3361

Ответ 1

CocoaPods создает неявный корневой объект, который по умолчанию связывается с первой целью проекта. Когда вы создаете другую цель, а опция link_with не наследуется дочерними целевыми определениями, ваша настройка не работает. Чтобы сделать параметр link_with, вы можете переместить его внутри блока целевого определения MyApp.

Поскольку общая целевая ссылка связывается с Pods, если вы связываете ее с MyApp, это приведет к ошибке повторяющихся символов, поскольку приложение связывается с Common. В этом случае вам просто нужно сделать заголовки доступными для цели MyApp. Это просто сделать, но пока нет надлежащего DSL, поэтому на данный момент немного взломано как решение (но поддерживается).

workspace 'MyApp.xcworkspace'
platform :ios, '5.0'

target 'Common' do
  pod 'AFNetworking',               '1.1.0'
  pod 'TTTAttributedLabel',         '1.6.0'
  pod 'JSONKit',                    '1.5pre'
  pod 'Reachability',               '3.1.0'

  target 'MyApp', :exclusive => true do
    xcodeproj 'MyApp.xcodeproj'
  end
end

Ответ 2

Решение, которое я принял для этой ситуации, выглядит следующим образом:

Я установил Podfile довольно просто:

workspace 'MyApp.xcworkspace'
platform :ios, '5.0'

xcodeproj 'Common.xcodeproj'

pod 'AFNetworking',               '1.1.0'
pod 'TTTAttributedLabel',         '1.6.0'
pod 'JSONKit',                    '1.5pre'
pod 'Reachability',               '3.1.0'

target 'MyApp' do
    xcodeproj 'MyApp.xcodeproj'
    # specific dependencies
end

Таким образом, Common lib и MyApp настроены правильно, чтобы использовать все зависимости. Однако это все равно вызовет дубликаты символов. Способ обойти это - просто удалить libPods.a из общей фазы сборки проекта. Это прекрасно, потому что мы действительно не хотим в любом случае ссылаться на статический lib Cocoapods на наш статический lib. Все правильные зависимости будут связаны при создании приложения, и все правильные пути заголовка настроены в файлах .xccconfig, поэтому Xcode/AppCode по-прежнему будет предоставлять все ваши автозавершения, и все будет компилироваться.

Вам нужно будет удалить libPods.a каждый раз, когда вы запустите pod install, что немного больно, но может быть лучше страдать, чем управлять всеми зависимостями вручную.

Обновление: Я работаю над этим, когда пишу, и я просто заметил, что важно не использовать компоновщики флагов компоновщика в вашей статической библиотеке. По умолчанию мой статический lib переопределил их значение без значения, но Cocoapods предупреждает об этом и советует использовать $(унаследованный). Просто проигнорируйте это.