XCode: Условные Настройки Сборки на основе архитектуры (Устройство (ARM) по сравнению со Средством моделирования (i386))
Большое спасибо за Ваши подсказки:
-
я пытаюсь зарегистрировать свой код так, как я могу, с помощью единых стандартов. Я пытаюсь думать о бедном парне, который, возможно, когда-нибудь приедет и иметь для поддержания моего кода (кто знает, возможно, тот парень мог быть я!).
-
я использую управление исходным кодом. Это - необходимость для меня, и я просто не могу работать без него.
-
Поблочное тестирование (разве это не третий pilar?)... Хорошо... Я не делаю никакого поблочного тестирования вообще: (и это - одна из вещей, которые я хотел бы изменить для будущих проектов.
-
, Когда я разрабатываю, я пытаюсь сделать заметки всех своих внутренних мыслей (это более или менее похоже говорящий с Вашим teddy, не так ли?).
-
у меня также есть Список ожидающих выполнения задач. Интересно, существует ли некоторое приложение (или веб-приложение) к лучше monitorize все эти задачи.
я буду смотреть к некоторым современным методологиям и пытаться включить некоторые методы к своей собственной методологии. Это кажется действительно интересным.
Теперь я также думаю об установке Круиз-контроля в моей машине, но это действительно стоило бы для меня?
5 ответов
Рекомендуемый способ сделать это - не добавлять библиотеку в проект и цель, а вместо этого установить флаги Other Linker Flags для включения отдельных прямых ссылок на библиотеку ссылок для каждого конфигурация.
Для отладки:
OTHER_LINKER_FLAGS = -l/Path/To/My/Debug/Library.dylib
Для выпуска
OTHER_LINKER_FLAGS = -l/Path/To/My/Release/Library.dylib
Вы, конечно, можете использовать ссылки на другие параметры сборки, чтобы сделать эти пути относительно чего-то надежного, или использовать дерево исходного кода для внешнего дерева исходного кода.
У вас есть 3 варианта:
Если вы контролируете, щелкните имя настройки сборки внутри Inspect Окно (где вы можете изменить настройки компилятора и т. Д.) Будет предлагать возможность условно обусловить этот параметр. Просто перейдите к флагам компоновщика, которые вы хотите изменить, и определите их с помощью SDK, затем введите конкретную библиотеку для каждого SDK.
В качестве альтернативы вы можете взять библиотеку и установить ее по тому же пути в каждом корне SDK ("/ Developer /Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib/ "и" /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/usr/lib "). Поскольку используются пути поиска относительных библиотек SDK, соответствующая версия будет использована для любой сборки.
Вы можете объединить две библиотеки в одну толстую библиотеку. Вероятно, это плохая идея, но если вы хотите это сделать, проверьте справочную страницу .
Для варианта 1 (см. ответ Луи Гербарга) в Xcode 3.2.1 выберите "Other Linker Flags", а затем выберите "Add Build Setting Condition" (Добавить состояние настройки здания) из выпадающего меню в нижней левой части окна настройки построения. См. ответ cdespinosa для синтаксиса "Другие флаги компоновки")
Или вы также можете "Добавить условие построения" в "Пути поиска библиотеки", если у вас есть библиотеки устройства/симулятора в отдельных каталогах.
Проблема с другими флагами компоновщика и добавлением библиотек заключается в контроле порядка компоновки библиотек, что может быть важным. Похоже, что версия флага компоновщика означает, что эти библиотеки будут первыми, поэтому, если вы управляете другими библиотеками в xcode, которые должны быть первыми, вам придется отказаться от этого и переместить все на другие флаги компоновщика ...! - P
В моем XCode 3.2.3 правильное именование выглядит как OTHER_LDFLAGS, а не OTHER_LINKER_FLAGS.