Как создать статическую библиотеку Objective-C для распространения в виде одного двоичного файла и файла заголовка?

Question

Я создаю статическую библиотеку MyLibrary для iOS в Objective-C, которая объединяет дюжину полезных классов, каждый из которых имеет свой собственный файл .h.Я хотел бы распространять MyLibrary как один скомпилированный двоичный файл, libMyLibrary.a, и один заголовочный файл .h, MyLibraryAPI.h.MyLibraryAPI.h имеет дюжину #import утверждений, по одному для каждого из дюжины открытых классов MyLibrary.Разработчики, которые хотят включить MyLibrary в свои хост-проекты, должны включать только двоичный файл libMyLibrary.a и заголовок MyLibraryAPI.h.Это и есть цель.

Итак, я установил Role каждого открытого класса в проекте MyLibrary Xcode на Public и успешно скомпилировал libMyLibrary.a, используя утилиты компоновки командной строки Xcode и lipo,Затем я вручную включил все дюжины MyLibrary заголовочных файлов вместе с libMyLibrary.a в хост-проект, и хост-проект может без проблем использовать публичные MyLibrary классы.Круто!

Проблема в том, что если я удаляю эти дюжины заголовочных файлов и вместо них использую MyLibraryAPI.h (как моя цель), классы хост-проекта больше не смогут найти заголовочные файлы MyLibrary, на которые есть ссылка в MyLibraryAPI.h,Вместо этого во время компиляции я получаю сообщения об ошибках: MyAwesomeThingDelegate.h: No such file or directory... для каждого MyLibrary класса, который я пытаюсь #import в MyLibraryAPI.h.У меня есть папка в корневом каталоге моего хост-проекта с именем lib, и в настройках сборки хост-проекта для пути поиска рекурсивного заголовка установлено значение lib/**, а в пути поиска библиотеки - для рекурсивного пути lib/**.

*.1034 * Мне бы очень хотелось услышать предложения сообщества о том, как правильно задать пути поиска хост-проекта, чтобы мне нужно было только включить libMyLibrary.a и MyLibraryAPI.h для использования классов MyLibrary.Или, если я делаю что-то не так, мне бы хотелось услышать еще одно предложение по достижению моей цели по распространению одного двоичного файла и одного заголовочного файла API.

Answer 1

Я даю второй ответ здесь с другим подходом.

Принцип работы Objective C заключается в том, что компилятору требуется полное объявление (т.е. файлы заголовков) всех классов, которые пользователиВаша библиотека будет напрямую звонить.Файл библиотеки (файл .a) содержит только скомпилированный код и не содержит декларации.Он будет использоваться только компоновщиком, который является одним из последних этапов создания приложения.

[Языки программирования, такие как C или C ++, одинаковы.Однако языки программирования, такие как Java или C #, хранят метаинформацию о классах в скомпилированном коде, поэтому им не нужны никакие заголовочные файлы, только файл .jar или .dll.]

Таким образом, один из подходов состоит в том, чтобы дать.a и каталог, полный заголовочных файлов для вашего пользователя.Затем они добавляют файл .a в свой проект, добавляют один оператор #import, где бы они ни использовали ваши классы, и добавляют путь к каталогу файла заголовка в свои настройки сборки (он называется «Пути поиска заголовка»).

Answer 2

У меня была такая же проблема, и я пришел со следующим решением:

Сначала я попытался скрыть как можно больше деталей реализации. По этой причине я обычно создавал пары классов: один класс является открытым интерфейсом, а другой - частной реализацией. Открытый класс имеет только один экземпляр члена: указатель на реализацию. Закрытый класс имеет только предварительное объявление.

@class MyViewImpl;

@interface MyView : UIView
{
    @private
    MyViewImpl* _internal;
}

@property (nonatomic, assign) CGRect highlightArea;
- (void) startAnimation;

@end

Во-вторых, я помещаю все публичные объявления в один заголовочный файл. С ним так же удобно работать, как и с отдельным заголовочным файлом, но это работает. Единственный оставшийся импорт - это импорт iOS-содержимого, например:

#import <UIKit/UIKit.h>