#c #xcode
Вопрос:
Я работаю над проектом Xcode c , состоящим из 2 целей. Этот проект должен быть скомпилирован как на Xcode 9.2, так и на последней версии Xcode.
- Цель 1-это просто вспомогательная цель; она создает фиктивное приложение cmdline hello world. Но целью злоупотребляют, прикрепляя к ней правило сборки, которое вызывает внешнюю утилиту для преобразования файлов .xyz в набор файлов .inc и .metal. В основном,
- совпадение файлов: .xyz
- пользовательский скрипт: …
- выходные файлы:
- $(INPUT_FILE_DIR)/$(INPUT_FILE_BASE).inc
- $(INPUT_FILE_DIR)/$(INPUT_FILE_BASE).металл
- Цель 2-это основное приложение, которое включает эти файлы .metal в качестве исходных файлов и в котором есть файлы .cpp, которые #включают эти файлы .inc.
- Цель 2 имеет цель 1 в качестве зависимости, чтобы гарантировать, что цель 1 обновит файлы .metal и .inc, когда это необходимо, до того, как цель 2 начнет компиляцию.
- Для файлов .xyz целевое членство установлено только для цели 1, а файлы .metal и .inc принадлежат только цели 2.
Это работает, поскольку все файлы .metal и .inc определенно обновляются при необходимости до того, как цель 2 начнет компиляцию.
Однако при создании этой вспомогательной цели 1 Xcode настаивает на том, чтобы также компилировать и связывать выходные файлы .metal правила сборки в двоичный файл цели 1 (я думаю). Как я могу предотвратить это? Это проблематично, потому что добавление этих файлов .metal завершает фазу соединения цели 1 (эти металлические файлы имеют собственные дополнительные зависимости).
Ранее в разделе вывода правила сборки цели 1 указывались только типы файлов .inc. Таким образом, эта настройка работает, предположительно, потому, что Xcode не имеет никакой связи с файлами .inc и, следовательно, не собирает их после их создания. Однако, чтобы убедиться, что проверка Xcode на актуальность также проверяет зависимость .xyz и результирующего файла .metal, я бы хотел, чтобы файл .metal также был указан в списке выходных файлов.
Я попытался поместить само правило сборки в цель 2, также красиво отрицая необходимость в этой вспомогательной цели 1, но тогда Xcode не правильно определяет порядок компиляции исходного файла. Если я удалю все полученные файлы .inc, Xcode с радостью сначала скомпилирует некоторые файлы .cpp, в которых эти файлы .inc являются #include
d, прежде чем перейти к вызову правила сборки .xyz -> .inc. Поэтому я предполагаю, что Xcode не учитывает сопоставление ввода-вывода правила сборки в дереве зависимостей сборки cpp-#включенные файлы-являются актуальными? Если вообще существует такая вещь, которая есть 🙂
I also tried negating the .metal files from being taken up by adding yet another build rule on target 1, this one specifying «metal files» and just not supplying any script. This does work.
Но я не могу поверить, что невозможно убедить Xcode игнорировать список выходных файлов правила сборки, не позволяя ему далее их компилировать/связывать…
Есть ли где-нибудь какие-либо настройки, контролирующие это поведение? Или, что еще лучше, есть ли способ, которым я могу поместить правило сборки в цель 2, одновременно включив #include
зависимость Xcode от cpp, как я не смог сделать выше?