Цикл зависимости фреймворка Xcode 10 от самого себя

В Xcode 10 я получаю эту ошибку сборки с одной из моих фреймворков, когда делаю инкрементную сборку (чистые сборки работают):

Showing All Messages
:-1: Cycle inside LoggingSharedFramework; building could produce unreliable results.
Cycle details:
→ Target 'LoggingSharedFramework' has a command with output 'blablabla/Build/Products/Debug-iphonesimulator/LoggingSharedFramework.framework/LoggingSharedFramework'
○ Target 'LoggingSharedFramework' has link command with output 'blablabla/Build/Intermediates.noindex/blablablah/Debug-iphonesimulator/LoggingSharedFramework.build/Objects-normal/x86_64/LoggingSharedFramework'
  • Фреймворк не имеет целевых зависимостей
  • Фаза заголовков предшествует компиляции исходных файлов.
  • Я просмотрел каждый файл и убедился, что нет никаких импортов, захватывающих файлы за пределами LoggingSharedFramework (кроме какао-материала)
  • Я не использую какую-либо систему управления зависимостями (например, carthage), потому что нет внешних зависимостей. Эта структура поддерживается в рамках проекта.

Для меня эта ошибка не имеет смысла. Какова настоящая причина? Как я могу понять, что представляет собой цикл? Как исправить цикл?

Вот журнал отладочной сборки, который я получаю:

Build system information
error: target:  ->

node: <all> ->

command: <all> ->

node: .../DerivedData/MyApp/Build/Products/Debug-iphoneos/LoggingSharedFramework.framework/LoggingSharedFramework ->

command: 60cc809630:Debug:CreateUniversalBinary .../DerivedData/MyApp/Build/Products/Debug-iphoneos/LoggingSharedFramework.framework/LoggingSharedFramework normal armv7 arm64 ->

node: .../DerivedData/MyApp/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/LoggingSharedFramework.build/Objects-normal/armv7/LoggingSharedFramework ->

command: 60cc809630:Debug:Ld .../DerivedData/MyApp/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/LoggingSharedFramework.build/Objects-normal/armv7/LoggingSharedFramework normal armv7 ->

node: .../DerivedData/MyApp/Build/Products/Debug-iphoneos/LoggingSharedFramework.framework/LoggingSharedFramework

** BUILD FAILED **

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

Раньше я думал, что исправил это, переместив фазу сборки заголовков раньше, исправив предупреждения зонтичного заголовка и очистив мою сборку. Но оказалось, что это было временное решение. Эта проблема, кажется, появляется снова случайным образом, и как только Xcode обнаружит цикл, он не исчезнет, ​​пока я снова не почищу. Затем он остается на какое-то время по какой-то неизвестной причине, и он возвращается.

Какую систему управления зависимостями вы используете? Не могли бы вы дать дополнительную информацию?

fewlinesofcode 11.10.2018 18:31

Нет, уточняется в вопросе

Max 11.10.2018 19:37

Вы пробовали удалить производные данные?

Ben Kane 11.10.2018 19:40

@BenKane, как упоминалось в вопросе, чистые сборки работают, но инкрементные сборки не работают. Выполнять чистую сборку каждый раз - это не «решение».

Max 11.10.2018 19:47

К сожалению, я упустил эту деталь.

Ben Kane 11.10.2018 19:48

Вы прочитали «Если цикл отображается только во время инкрементных сборок» эта страница справки Xcode 10?

Ben Kane 11.10.2018 19:56

@BenKane следующие шаги: 1. удалить целевые зависимости (у меня их нет) 2. удалить операторы импорта (я искал вручную и не нашел ни одного, который мог бы указывать на цикл) и 3. реструктурировать исходный код (я готов, а где же цикл !? не знаю что реструктурировать)

Max 11.10.2018 19:58

Если вы можете создать небольшой проект, в котором воспроизводится проблема, я буду рад взглянуть

Ben Kane 11.10.2018 20:01

Можете ли вы добавить результат, полученный после запуска defaults write com.apple.dt.XCBuild EnableDebugActivityLogs -bool YES в терминале, а затем повторного построения?

Ben Kane 11.10.2018 20:07

@BenKane Я собирался попробовать EnableDebugActivityLogs, но сначала решил, что нужно убрать все нерелевантные предупреждения в фреймворке, чтобы ошибка была более очевидной. Но исправление предупреждений в заголовке зонтика привело меня к решению, которое я опубликовал ниже. Спасибо за ваши предложения.

Max 12.10.2018 20:25

Рад видеть, что вы смогли это исправить

Ben Kane 12.10.2018 20:48

@Max Почему вы удалили свой ответ?

matt 15.10.2018 16:22

Проблема возникла в других фреймворках, и мой ответ ее не решил.

Max 15.10.2018 22:30

@BenKane Я добавил к своему вопросу журнал отладочной сборки. У меня все еще возникает эта проблема. Приветствуется любое понимание.

Max 11.03.2019 15:51

Какой смысл в награде за вопрос, на который вы уже ответили?

matt 11.03.2019 16:33

@matt Я думал, что мой ответ сработал, но это не так. Я забыл удалить это

Max 11.03.2019 17:06

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

matt 11.03.2019 18:16

@Max Если вы можете создать небольшой проект, в котором воспроизводится проблема, я буду рад взглянуть

staticVoidMan 18.03.2019 14:47

@staticVoidMan из моего списка дел. Код, в котором появляется цикл, к сожалению, большой и проприетарный, поэтому он нетривиален.

Max 18.03.2019 15:43

@Max Хорошо, это в основном проблема конфигурации проекта. Но для начала, в LoggingSharedFramework вы проверяли Xcode Project Settings > Build Phases > Compile Sources на наличие файлов, которых там не должно быть?

staticVoidMan 19.03.2019 06:31

Из примечаний к выпуску Xcode 10.2: «Публичные заголовки в структуре могут ошибочно #import или #include private headers, что вызывает нарушения слоев и потенциальные циклы модулей. Есть новая диагностика, которая сообщает о таких нарушениях. По умолчанию в clang она отключена и контролируется флаг -Wframework-include-private-from-public ". Как только эта проблема возникнет снова, я протестирую это

Max 29.03.2019 14:09

Это снова появилось в Xcode 12.4 ...

Parth Tamane 08.06.2021 17:09

@ParthTamane У меня давно не было этой проблемы, даже с Xcode 12.4. Вы пробовали проверить это предупреждение в моем предыдущем комментарии?

Max 08.06.2021 19:55

Какое предупреждение? Также как включить Wframework-include-private-from-public flag?

Parth Tamane 02.07.2021 21:32
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
13
24
4 923
4
Перейти к ответу Данный вопрос помечен как решенный

Ответы 4

В этой ситуации я бы предпринял следующие шаги:

Если цель LoggingSharedFramework поддерживается в более крупном проекте:

  1. Изолируйте его в отдельный проект
  2. Удалите все файлы LoggingSharedFramework и импортированные из содержащего проекта
  3. Создайте фреймворк толстый и добавьте его в проект как встроенный фреймворк.
  4. Проверьте, сохраняется ли ошибка

Если LoggingSharedFramework уже является отдельным проектом:

  1. Проверьте каждый файл и удалите весь ненужный импорт (включая материал какао)
  2. Проверьте этап linking и связанные сценарии сборки и удалите все ненужное.

Всегда стоит попробовать Включение / отключение параллельных сборок

Думаю, вы уже все это прошли, но удачи!

Я сталкивался с этой ошибкой пару раз, но это то, что у меня сработало.

1) Я перехожу в Xcode -> Preferences -> Locations, очищаю все производные данные и закрываю Xcode.

2) Если вы используете стручки какао, удалите файл рабочей области (.xcworkspace) и каталог Podile /.

3) Перейдите в свой проект и запустите установку pod.

4) Откройте свой проект через Xcode, очистите и соберите.

5) Запустите проект, и все должно работать нормально.

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

Max 18.03.2019 13:14

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

exec > /tmp/${PROJECT_NAME}_archive.log 2>&1

UNIVERSAL_OUTPUTFOLDER=${BUILD_DIR}/${CONFIGURATION}-universal

if [ "true" == ${ALREADYINVOKED:-false} ]
then
echo "RECURSION: Detected, stopping"
else
export ALREADYINVOKED = "true"

# make sure the output directory exists
mkdir -p "${UNIVERSAL_OUTPUTFOLDER}"
#mkdir -p "${UNIVERSAL_OUTPUTFOLDER}/${TARGET_NAME}.framework" 

echo "Building for iPhoneSimulator"
xcodebuild -workspace "${WORKSPACE_PATH}" -scheme "${TARGET_NAME}" -configuration ${CONFIGURATION} -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone XS' ONLY_ACTIVE_ARCH=NO ARCHS='i386 x86_64' BUILD_DIR = "${BUILD_DIR}" BUILD_ROOT = "${BUILD_ROOT}" ENABLE_BITCODE=YES OTHER_CFLAGS = "-fembed-bitcode" BITCODE_GENERATION_MODE=bitcode clean build

# Step 1. Copy the framework structure (from iphoneos build) to the universal folder
echo "Copying to output folder"
cp -R "${ARCHIVE_PRODUCTS_PATH}${INSTALL_PATH}/" "${UNIVERSAL_OUTPUTFOLDER}"

# Step 2. Copy Swift modules from iphonesimulator build (if it exists) to the copied framework directory
SIMULATOR_SWIFT_MODULES_DIR = "${BUILD_DIR}/${CONFIGURATION}-iphonesimulator/${TARGET_NAME}.framework/Modules/${TARGET_NAME}.swiftmodule/."
if [ -d "${SIMULATOR_SWIFT_MODULES_DIR}" ]; then
cp -R "${SIMULATOR_SWIFT_MODULES_DIR}" "${UNIVERSAL_OUTPUTFOLDER}/${TARGET_NAME}.framework/Modules/${TARGET_NAME}.swiftmodule"
fi

# Step 3. Create universal binary file using lipo and place the combined executable in the copied framework directory
echo "Combining executables"
lipo -create -output "${UNIVERSAL_OUTPUTFOLDER}/${EXECUTABLE_PATH}" "${BUILD_DIR}/${CONFIGURATION}-iphonesimulator/${EXECUTABLE_PATH}" "${ARCHIVE_PRODUCTS_PATH}${INSTALL_PATH}/${EXECUTABLE_PATH}"

echo "Combining executables end"

# Step 4. Create universal binaries for embedded frameworks
for SUB_FRAMEWORK in $( ls "${UNIVERSAL_OUTPUTFOLDER}/${TARGET_NAME}.framework/Frameworks" ); do
BINARY_NAME = "${SUB_FRAMEWORK%.*}"
echo "${ARCHIVE_PRODUCTS_PATH}${INSTALL_PATH}/${TARGET_NAME}.framework/Frameworks/${SUB_FRAMEWORK}/${BINARY_NAME}"
lipo -create -output "${UNIVERSAL_OUTPUTFOLDER}/${TARGET_NAME}.framework/Frameworks/${SUB_FRAMEWORK}/${BINARY_NAME}" "${BUILD_DIR}/${CONFIGURATION}-iphonesimulator/${SUB_FRAMEWORK}/${BINARY_NAME}" "${ARCHIVE_PRODUCTS_PATH}${INSTALL_PATH}/${TARGET_NAME}.framework/Frameworks/${SUB_FRAMEWORK}/${BINARY_NAME}"
done

# Step 5. Convenience step to copy the framework to the project's directory
echo "Copying to project dir"
yes | cp -Rf "${UNIVERSAL_OUTPUTFOLDER}/${FULL_PRODUCT_NAME}" "${PROJECT_DIR}"

open "${PROJECT_DIR}"

fi

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

Max 18.03.2019 15:42
Ответ принят как подходящий

Эта проблема, похоже, решилась сама собой в Xcode 10.2.

Другие вопросы по теме