2013-05-28 3 views
5

Я разрабатываю достаточно сложное приложение для iOS. Чтобы рационализировать разработку, я начал разрабатывать каждый модуль как отдельный проект, который затем составляется вместе в проекте приложения верхнего уровня, что приводит к дереву зависимостей.Как управлять деревом зависимостей, содержащим дубликаты зависимостей? (XCode, iOS)

Я принял этот подход успешно, но на этот раз имеет общую зависимость (C), которая вызывает проблему:

 A 
    /|\ 
/| \ 
    B C D 
/\  \ 
C E  C 

Где А проект приложения верхнего уровня, а С ' Основная библиотека "функций. Эта основная библиотека является зависимостью от самого А, а также от модулей B и D. Результирующая множественная компиляция вызывает дубликаты символов в папке сборки и неудачную привязку.

Теперь я могу быть прагматичным и просто удалять ссылку из A, поскольку это все равно будет скомпилировано в папку сборки B, и если D не будет задействован, это будет просто работать. Но как я могу решить проблему дублирования зависимости C от B и D? Проектам, D B и еще нужна ссылка на C, когда я скомпилировать их автономные, но столкновение при компиляции дважды в контексте А.

Я могу представить себе некоторые запутанные решения с использованием objcopy и даю им уникальные префиксы , но это будет несколько неэффективно, поскольку это тот же код. Я мог бы жить с этим, но есть ли лучший способ? Возможно, некоторый флаг компилятора или компоновщика для повторного использования существующего символа в папке сборки, если он существует, вместо повторной компиляции?

Спасибо за любой совет.

+0

Технически, это тот же самый вопрос: http://stackoverflow.com/questions/11784917/how-do-i-resolve-avoid-duplicate-symbols-in-common-transitive-xcode-dependencies . .. но он не получил адекватного ответа. –

+0

Я не вижу проблемы, статическая библиотека при построении не связывается с другими библиотеками, но предоставляет зависимости, которые разрешаются только тогда, когда эта библиотека связана с исполняемым файлом. В вашем случае «A». Похоже, что B, C, D, E не являются статическими библиотеками, иначе ваш вопрос не имеет смысла. – Till

+0

@ Завершить: «статическая библиотека при построении не связывается с другими библиотеками». Да, это так, это была проблема! Во всяком случае, с тех пор я решил эту проблему, явно опуская этап компоновки для целей ниже верхнего уровня, что затем приводит к описанному вами поведению. –

ответ

0

Решение, которое работало лучше для меня имеет две цели в каждом проекте модуля: < Имя_целевого_объекта > и один я назвал < Имя_целевого_объекта > -NoLink.

Эти две цели идентичны, за исключением того, что этап связывания опущен в -NoLink. В результате создаются только промежуточные файлы .o, и сборка может полностью продвигаться к корневому проекту, который, наконец, равен, связанный со всеми модулями.

Связанный целевой < Имя_целевого_объекта > остается, сохраняя гибкость, чтобы связать все зависимости в любой точке дерева, производя автономный .a файл для любого модуля.

Смежные вопросы