Покрытие кода на iOS Использование Xcode 4.2 на Lion

Я пытаюсь создать gcd файлы из проекта iOS Xcode 4.2 (4D199) под названием CocoaTouchHax на Lion, и у меня возникают невероятные проблемы. Я выполнил шаги, описанные здесь, и даже попытался собрать llvm/clang. из исходного кода, выполнив шаги здесь. Однако я продолжаю получать эту ошибку:

Library not loaded: @executable_path/../lib/libprofile_rt.dylib

Где я ошибаюсь? Я пытался использовать install_name_tool, чтобы исправить путь к исполняемому файлу, но безрезультатно. Я что-то анализирую? Я пропустил что-то простое? Я помещаю это как фазу «Выполнить скрипт» перед связыванием, чтобы убедиться, что я обновил путь @executable, и я использую инструмент для проверки файла после обновления имени:

install_name_tool -id @executable_path/Users/cliff/dev/CocoaTouchHax/build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib

Что я делаю неправильно? Помощь!

Обновление Простое добавление lib profile_rt.dylib приводит к сбою моего тестового запуска, немедленно выдавая следующую ошибку при любом запуске: @executable_path/../lib/libprofile_rt.dylib Так что я уверен, что что-то должно произойти или что-то в этом роде необходимо сделать с lib profile_rt.dylib перед выполнением.

Еще одно обновление. Я попытался создать ссылку суммы на /Developer/usr/lib в папке /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/Developer/usr, которая, как мне кажется, является частью базы путь, формирующий текущий рабочий каталог при запуске теста. (Предполагая, что он запускается из папки bin там.) Теоретически это завершит относительный путь поиска ../lib/libprofile_rt.dylib из этого базового пути, но это не сработало. Я пытался запустить команду install_name_tool перед копированием dylib на место, но все равно получаю эту ошибку:

Библиотека не загружена: @executable_path/../lib/libprofile_rt.dylib

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


code-coverage ios5 xcode4.2
person Cliff    schedule 10.12.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

В Lion вы можете сделать символическую ссылку на dylib в /usr/lib, чтобы избежать этой ошибки.

sudo ln -s /Developer/usr/lib/libprofile_rt.dylib /usr/lib/libprofile_rt.dylib

Однако я не могу гарантировать, что это не сломает что-то в будущем. Помните, что вы сделали это.

Создайте новую конфигурацию под названием «Покрытие» (или что-то подобное).

В созданном вами варианте конфигурации покрытия перейдите в Настройки сборки и...

  • Добавьте -fprofile-arcs и -ftest-coverage к Другим флагам C.
  • Включите Generate Test Coverage Files
  • Включите Instrument Program Flow
  • В разделе Другие флаги компоновщика добавьте -lprofile_rt

Причина, по которой это делается с конфигурацией, заключается в том, что вы можете сохранить свою обычную сборку нетронутой. Также работает только на Симуляторе. Так что не пытайтесь запустить это на устройстве.

И из http://mattrajca.com/post/8749868513/llvm-code-coverage-and-xcode-4

Наконец, откройте подпапку Intermediates/$TARGET.build/$CONFIG/$TARGET.build/Objects-normal/$ARCH. Внутри вы найдете вышеупомянутые файлы gcda и gcov

Вы можете открыть эту папку с помощью CoverStory.

Обратите внимание, что покрытие не является кумулятивным (в отличие от покрытия), поэтому каждый запуск начинается заново. Возможно, есть способ изменить это.

person Warren Burton    schedule 09.01.2012
comment
Спасибо!!! Недостающая ссылка была символической ссылкой из папки /usr/lib! Рабочая папка должна быть папкой /usr/bin, что объясняет, почему мои предыдущие попытки создать символическую ссылку не сработали. Я предполагал, что рабочая папка будет расположением исполняемого файла модульного теста /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/Developer/usr. Теперь я вижу свои файлы покрытия! Еще раз спасибо!!! :) :) - person Cliff; 10.01.2012

arrow_upward
5
arrow_downward

Обновление: в Xcode 4.3.2 (4E2002) просто включите Создать файлы тестового покрытия и Программный поток инструмента. , система сборки свяжет для вас libprofile_rt. Xcode 4.3 и более поздние версии являются стандартным приложением для Mac, а папка /Developer исчезла. Итак, пропустите шаги 5-7 ниже. Вам также потребуется создать файл класса для обхода ошибки в реализации Unix от Apple, как описано здесь. Вам понадобится это в тестируемом проекте.

Для Xcode 4.2 (4C199) в Snow Leopard:

  1. Создайте проект, скажем, MyProduct. Установите флажок Включить модульные тесты.
  2. Как только Xcode сделает свое дело и загрузит новый проект, у вас должно быть две цели: MyProduct и MyProductTests. Дублируйте цель MyProduct.
  3. Выберите цель Копия MyProduct.
  4. Перейдите в Настройки сборки. В разделе Генерация кода включите Создать файлы тестового покрытия и Программный поток прибора.
  5. Перейдите к Этапам сборки. Разверните узел Связать двоичный файл с библиотеками. Нажмите +. Нажмите Добавить другое.... Перейдите в /Developer/usr/lib. Выберите libprofile_rt.dylib.
  6. Выберите цель MyProductTests.
  7. Повторите шаги 4 и 5 для этой цели.
  8. Снова перейдите в Настройки сборки. Найдите Bundle Loader в разделе Связывание. Измените путь к приложению Копия MyProduct. Что-то вроде $(BUILT_PRODUCTS_DIR)/MyProduct copy.app/MyProduct copy.
  9. Измените свои схемы, чтобы тесты выполнялись по схеме MyProduct copy, а не MyProduct. Если вы компилируете clang самостоятельно, вы можете узнать подробности здесь.

Это должно сработать. Шаг 8 занял у меня часы, чтобы понять, что это ключ. Если вы видите только файлы gcda в каталоге тестовой сборки, скорее всего, это проблема.

person ageektrapped    schedule 12.12.2011
comment
Да, я знаю про запуск на симке против устройства. У меня возникла проблема с llvm/clang, скомпилированным из исходного кода, где lib profile_rt.dylib поддерживал только архитектуру x64. Поэтому я вернулся к использованию библиотеки profile_rt.dylib, поставляемой с Xcode. Мой вопрос в 2 раза. Нужно ли собирать clang из исходников или Apple исправила это в последней версии Xcode 4.2 (4D199)? Кроме того, что-то не так с относительным путем @executable в libprofile_rt.dylib? - person Cliff; 12.12.2011
comment
Я только что прошел и тщательно попытался следовать вашим инструкциям. Я все еще получаю: dyld: Библиотека не загружена: @executable_path/../lib/libprofile_rt.dylib Я думаю, что должно быть изменение между Xcode 4.2 (4C199) и Xcode 4.2 (4D199), которое представляет это. - person Cliff; 13.12.2011
comment
Вау, облом. Я на Снежном Барсе. Я думаю, что это могло бы объяснить несоответствие с номерами версий. Опыт научил меня, что вполне возможно, что то, что поставляла Apple, представляет собой глючную кашу. Я удивлен, что это вообще работает, на самом деле. - person ageektrapped; 14.12.2011
comment
+1 за подробное объяснение для пользователей SnowLeopard. Я все еще работаю над решением Lion... :( :( - person Cliff; 16.12.2011
comment
Что вам напечатает otool -L /Developer/usr/lib/libprofile_rt.dylib? Мне интересно, как для вас выглядит @executable_path. - person Cliff; 16.12.2011
comment
Одна вещь, которую мне пришлось сделать, — это установить один и тот же тип компилятора (Apple LLVM Compiler 3.0) как для приложений, так и для целей тестов. В противном случае файлы .gcda и .gcno не будут созданы для файлов цели приложения. Однако я не создавал копию цели приложения. - person tmin; 11.02.2012