#c #xcode #macos #dylib #dynamic-library
#c #xcode #macos #dylib #динамическая библиотека
Вопрос:
У нас есть приложение для Windows, написанное на C , часть которого мы пытаемся перенести на Mac OS X. Наша цель — обернуть бизнес-логику в некоторые библиотеки и создать слой Cocoa поверх контроллера и графического интерфейса. Вероятно, у нас будет несколько приложений меньшего размера, использующих одни и те же библиотеки, поэтому нашей первой мыслью было использовать динамические библиотеки для кода C (если нет лучшего способа). Однако у нас возникают некоторые проблемы с достижением этого. Наша динамическая библиотека соответствует требованиям (по крайней мере, так выглядит), и мы получаем файл .dylib, на который мы ссылаемся в нашем приложении. Проблема в том, что наше приложение просто не может найти ни один из файлов .h, которые мы пытаемся включить. Мы уже проверили, экспортируются ли файлы .h, а также проверили имя установки и убедились, что библиотека расположена в правильном каталоге. Кроме того, мы следовали руководству Apple по созданию и использованию динамических библиотек и не обнаружили никаких специальных шагов, которые мы пропустили.
Мой вопрос здесь состоит из двух частей:
- Есть ли какой-то очевидный шаг, который мы могли бы пропустить, который играет важную роль в раскрытии интерфейса (т. Е. Файлов .h), который мы должны попробовать перед чем-либо еще?
- Мы подозреваем, что ошибка может быть в дрянном коде C , который мы унаследовали в этом проекте. Например, существует много логики (реализация методов), записанных непосредственно в файлах .h, а в некоторых случаях даже нет соответствующего файла .cpp. Таким образом, файлы .h — это не просто описание интерфейса. Возможно, это не самая серьезная проблема, поскольку наше приложение даже не может найти файлы .h из библиотеки, а они должны хотя бы присутствовать. Мы действительно надеемся, что сможем избежать переписывания большого количества кода, поскольку кодовая база, которую необходимо перенести, действительно велика, и (как обычно) крайний срок близок.
PS: До сих пор мы работали только в Xcode 4.2 и еще не пробовали использовать инструменты командной строки.
Комментарии:
1. Убедитесь, что вы указали путь к включаемым файлам вашей библиотеки в настройках сборки вашего проекта / цели: пути поиска заголовка или пути поиска пользовательского заголовка.
2. Убедитесь, что файлы заголовков находятся там, где вы ожидаете их (в файловой системе)
3. На самом деле мы сделали это из чистого отчаяния, и это вроде как сработало. Но действительно ли это необходимо? Я имею в виду, это означает, что когда вы распространяете библиотеку, вы также должны распространять файлы заголовков. Итак. dylib не работает аналогично DLL-файлу в Windows, который является полностью автономным?
4. В этом случае мы должны вместо этого изучить фреймворки (которые также упаковывают файлы заголовков, если я правильно понимаю). Каковы будут последствия, если мы захотим использовать его в нескольких приложениях?
5. @NobleK Вам не нужно отправлять заголовочные файлы в ваше приложение . С другой стороны, если вы отправляете свою библиотеку для использования другими разработчиками, то да, вам также нужно отправлять заголовочные файлы, и для этого вы можете использовать фреймворки.
Ответ №1:
Вариант 1
В этом случае я бы просто добавил каталог, содержащий заголовки, в пути обнаружения заголовков или библиотек в Xcode. В зависимости от макета некоторые подходы будут лучше других.
Как правило, вы будете использовать некоторую комбинацию:
HEADER_SEARCH_PATHSLIBRARY_SEARCH_PATHSUSER_HEADER_SEARCH_PATHS- или
FRAMEWORK_SEARCH_PATHS
Какой из них правильный, зависит от используемой библиотеки (например, эти параметры также могут влиять на компоновщик). При определении путей обнаружения вы можете добавить суффикс ** для обозначения рекурсивного поиска.
Это идеально, потому что у вас будет меньше проблем с синхронизацией ваших проектов xc с их решениями vs.
Вариант 2
Некоторым людям действительно нравится поддержка перетаскивания для их включений… Я этого не делаю, но это подход, если существует такая большая дезорганизация, что вы не можете просто сделать что-то такое простое, как добавление пути поиска:
- добавьте необходимые заголовки в проект
- добавьте эти заголовки на этап сборки заголовков копирования целевого объекта
- повторяйте, пока он не соберется, и будьте готовы к поломке при слиянии / извлечении их обновлений.
это быстро запутывается и требует часов для восстановления, когда вы хотите повторно использовать библиотеку, если есть коллизии в именах заголовков.
Комментарии:
1. Спасибо за ответ, как здесь, так и в вашем комментарии выше.