Дублирующее определение интерфейса при смешивании файлов Objective-C в проектах в XCode - PullRequest
1 голос
/ 21 декабря 2010

У меня есть ситуация, когда у меня есть один проект XCode, и у меня есть другой проект, который разделяет большую часть кода с некоторыми небольшими отличиями. Таким образом, в проекте большинство файлов являются просто ссылками на файлы из исходного проекта, и везде, где мне нужно внести изменения, я копирую файл и изменяю копию. Это полезно, потому что для файлов, к которым предоставлен общий доступ, любые изменения, сделанные в одном проекте, будут автоматически отражены в другом. Это работало нормально по большей части.

Теперь я столкнулся с проблемой, когда мне нужно внести изменения в заголовочный файл, который включен в большое количество файлов. Назовите этот файл «shared.h». Поэтому я делаю то же самое, что и раньше, удаляю ссылку, копирую файл и меняю его.

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

Причина в том, что предположим, что у вас есть файл, который включает заголовки как исходного проекта, так и нового проекта. В файлах, которые являются ссылками на исходный проект, когда вы делаете #import "shared.h", они будут импортировать файл из каталога исходного проекта; и в файлах, которые копируются в новый проект, когда вы делаете #import "shared.h", они импортируют файл из каталога нового проекта. Таким образом, классы, определенные в заголовке, будут дважды импортированы в два разных файла, поэтому вы получите дублированное определение интерфейса. Objective-C #import будет включать один раз для каждого файла, но, поскольку это два разных файла, он все равно будет включать оба из них.

Я думал, что заголовок, который фактически указан в моем проекте, будет иметь приоритет над всем остальным (по крайней мере, я хочу, чтобы он это делал), но, похоже, что размещение заголовков в проекте на самом деле не влияет на сборку кода в все. Так что теперь я потерялся.

Единственное решение, которое я могу придумать на данный момент, - это продублировать весь код в исходном проекте и переместить его, чтобы полностью отделить проекты. Но это ужасно.

1 Ответ

1 голос
/ 21 декабря 2010

Хм, я действительно думаю, что это больше проблема управления проектами.Я думаю, что ссылки в коде из другого проекта звучат очень хрупко.Т.е., если проект A является исходным проектом, а проект B связан в некотором его коде, изменения в проекте A могут нарушить проект B, если у проекта B нет возможности ограничивать или контролировать влияние этих изменений.

I 'Рассмотреть возможность компиляции первого проекта в виде статической библиотеки или фреймворка и присвоения ему номера версии.Затем второй проект может импортировать библиотеку.Переопределения не должны обрабатываться путем эффективного манипулирования путем классов.Я видел, как это делается на Java, и это всегда последний способ обойти плохой код.Вместо этого вы должны использовать возможности Objective C - наследование, категории и т. Д. Для добавления или расширения функциональности.

Если вы вернули первый проект (т.е. /v0.0.1/headers), тогда проект B может сохранитьиспользуя v0.0.1 из A, пока вы не прочитаете, чтобы обновить до v0.0.2.Затем вы можете повторно импортировать статическую библиотеку A, обновить путь сборки или что-то еще, чтобы указать B на новую версию, для которой вы хотите кодировать.

Таким образом, я бы вообще не рекомендовал вашу технику управления проектами и настоятельно рекомендую вам переосмыслить ее.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...