Цикл зависимостей фреймворка 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 (кроме материалов Cocoa).
  • Я не использую никакую систему управления зависимостями (например, 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 обнаруживает цикл, она не исчезнет, ​​пока я снова не очистю. Затем оно какое-то время исчезает, и какая-то неизвестная причина возвращает его.


person Max    schedule 09.10.2018    source источник
comment
Какую систему управления зависимостями вы используете? Не могли бы вы дать больше информации?   -  person fewlinesofcode    schedule 11.10.2018
comment
Нет, уточняется в вопросе   -  person Max    schedule 11.10.2018
comment
Вы пробовали удалить производные данные?   -  person Ben Kane    schedule 11.10.2018
comment
@BenKane, как упоминалось в вопросе, чистые сборки работают, но добавочные сборки терпят неудачу. Делать чистую сборку каждый раз — не решение   -  person Max    schedule 11.10.2018
comment
Извините, я пропустил эту деталь.   -  person Ben Kane    schedule 11.10.2018
comment
Читали ли вы, если цикл сообщается только во время добавочных сборок этого Xcode 10 страница справки?   -  person Ben Kane    schedule 11.10.2018
comment
@BenKane шаги: 1. удалить целевые зависимости (у меня их нет) 2. удалить операторы импорта (я искал вручную и не нашел ничего, что могло бы указывать на цикл) и 3. реструктурировать исходный код (я готов, а где цикл!?не знаю на что перестроиться)   -  person Max    schedule 11.10.2018
comment
Если вы можете создать небольшой проект, который воспроизводит проблему, я был бы рад взглянуть   -  person Ben Kane    schedule 11.10.2018
comment
Можете ли вы добавить вывод, который вы получите после запуска defaults write com.apple.dt.XCBuild EnableDebugActivityLogs -bool YES в терминале, а затем снова построить?   -  person Ben Kane    schedule 11.10.2018
comment
@BenKane Я собирался попробовать EnableDebugActivityLogs, но сначала подумал, что должен убрать все неуместные предупреждения в фреймворке, чтобы ошибка была более очевидной. Но исправление предупреждений в заголовке зонтика привело меня к решению, которое я опубликовал ниже. Спасибо за ваши предложения.   -  person Max    schedule 12.10.2018
comment
Рад видеть, что вы смогли это исправить   -  person Ben Kane    schedule 12.10.2018
comment
@Max Почему ты удалил свой ответ?   -  person matt    schedule 15.10.2018
comment
Проблема появилась в других фреймворках, и мой ответ ее не решил.   -  person Max    schedule 15.10.2018
comment
@BenKane Я добавил журнал отладочной сборки к своему вопросу. Я все еще получаю эту проблему. Мы будем очень признательны за любое понимание.   -  person Max    schedule 11.03.2019
comment
В чем смысл вознаграждения за вопрос, на который вы уже ответили?   -  person matt    schedule 11.03.2019
comment
@matt Я думал, что мой ответ сработал, но это не так. я забыл его удалить   -  person Max    schedule 11.03.2019
comment
Хорошо, но вы можете уточнить, добавив свое «неудачное» решение к своему вопросу, чтобы люди поняли, что вы пробовали и почему это не сработало. На самом деле вы не задаете этот вопрос таким образом, чтобы получить полезные ответы. 500 повторений — большая награда; вы должны быть максимально ясными и полными, иначе вы можете просто потерять представителя, не получив хорошего ответа.   -  person matt    schedule 11.03.2019
comment
@Max Если вы можете создать небольшой проект, который воспроизводит проблему, я был бы рад взглянуть   -  person staticVoidMan    schedule 18.03.2019
comment
@staticVoidMan, это в моем списке дел. Код, в котором появляется цикл, к сожалению, большой и проприетарный, поэтому он нетривиален.   -  person Max    schedule 18.03.2019
comment
@Max Хорошо, это в основном проблема конфигурации проекта. Но для начала, в LoggingSharedFramework вы проверили Xcode Project Settings > Build Phases > Compile Sources файлы, которых там быть не должно?   -  person staticVoidMan    schedule 19.03.2019
comment
Из примечаний к выпуску Xcode 10.2 Общедоступные заголовки в фреймворке могут ошибочно #import или #include частные заголовки, что вызывает нарушения многоуровневости и потенциальные циклы модулей. Есть новая диагностика, которая сообщает о таких нарушениях. По умолчанию в clang он выключен и контролируется флагом -Wframework-include-private-from-public. Как только эта проблема появится снова, я проверю это   -  person Max    schedule 29.03.2019
comment
Это снова появилось в Xcode 12.4...   -  person Parth Tamane    schedule 08.06.2021
comment
@ParthTamane У меня давно не было этой проблемы, даже с Xcode 12.4. Вы пробовали проверить это предупреждение в моем предыдущем комментарии?   -  person Max    schedule 08.06.2021
comment
Какое предупреждение? Кроме того, как включить Wframework-include-private-from-public flag?   -  person Parth Tamane    schedule 02.07.2021


Ответы (4)


Шаги, которые я бы предпринял в этой ситуации, были бы следующими:

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

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

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

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

Также стоит попробовать включить/отключить параллельные сборки.

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

person fewlinesofcode    schedule 12.10.2018

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

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

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

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

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

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

person Vision Mkhabela    schedule 16.03.2019
comment
Да, чистые сборки всегда работают. Но чистые сборки занимают намного больше времени, чем инкрементные сборки, и это исправление по-прежнему носит временный характер, поскольку циклы случайным образом появляются позже. - person Max; 18.03.2019

Я предполагаю, что 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

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

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

person Max    schedule 23.04.2019