Почему MSBuild создает файлы .tlog в CMakeFiles / CompilerIdC и как мне это остановить? - PullRequest
0 голосов
/ 28 июня 2018

У меня есть проект CMake, и одна из моих сборок находится на Visual Studio, с использованием MSBuild, на сервере сборки TeamCity.

Я вижу частые сбои при запуске git clean -f -d -x (шаг, который TeamCity выполняет самостоятельно при инициализации сборки, как часть проверки исходного кода). Причина сбоя заключается в том, что .tlog файлы генерируются в моей папке сборки CMake - во внутреннем проекте CompilerIdC CMake, который CMake использует для идентификации локального компилятора Си.

Для чего нужны .tlog файлы и что вызывает их создание? Я не нашел документации для этого.

Я не понимаю, почему они появляются после Запуск и сборка CMake уже завершены. Я особенно не понимаю, почему они создаются более чем через пятнадцать минут после удаления всех исходных и проектных файлов CompilerIdC.

Подробнее

Файлы генерируются в ${CMAKE_BUILD_DIR}/CMakeFiles/3.5.2/CompilerIdC/Debug/CompilerIdC.tlog. Они все в форме link-VCTIP.(read|write|delete).*.tlog.

Вот состояние папки для сборки, которая завершилась с ошибкой git clean и остановилась в 08:41 (по состоянию на 09:30):

-rw-r--r-- 1 CI 197121  570 Jun 28 08:57 link-VCTIP.delete.1.tlog
-rw-r--r-- 1 CI 197121 1422 Jun 28 08:57 link-VCTIP.delete.26.tlog
-rw-r--r-- 1 CI 197121 7062 Jun 28 08:57 link-VCTIP.read.1.tlog
-rw-r--r-- 1 CI 197121  402 Jun 28 08:50 link-VCTIP.read.103.tlog
-rw-r--r-- 1 CI 197121  402 Jun 28 08:55 link-VCTIP.read.120.tlog
-rw-r--r-- 1 CI 197121  418 Jun 28 08:57 link-VCTIP.read.26.tlog
-rw-r--r-- 1 CI 197121  286 Jun 28 08:57 link-VCTIP.read.27.tlog
-rw-r--r-- 1 CI 197121  286 Jun 28 08:57 link-VCTIP.read.28.tlog
-rw-r--r-- 1 CI 197121  286 Jun 28 08:57 link-VCTIP.read.29.tlog
-rw-r--r-- 1 CI 197121  402 Jun 28 08:45 link-VCTIP.read.87.tlog
-rw-r--r-- 1 CI 197121  600 Jun 28 08:57 link-VCTIP.write.1.tlog
-rw-r--r-- 1 CI 197121  286 Jun 28 08:57 link-VCTIP.write.26.tlog

Журнал сборки выглядит так:

[08:39:58][VCS Root: MyVCS] [D:\TeamCity\buildAgent\work\58a2d5637a76fb3e]: "C:\Program Files\Git\bin\git.exe" clean -f -d -x
[08:41:26][VCS Root: MyVCS] warning: failed to remove build/Windows-x64-Release/: Directory not empty
[08:41:27]
[Updating sources] Failed to perform checkout on agent: '"C:\Program Files\Git\bin\git.exe" clean -f -d -x' command failed.
stdout: Removing Artifacts/x64/
<snip>
Removing build/Windows-x64-Release/CMakeFiles
<snip>
stderr: warning: failed to remove build/Windows-x64-Release/: Directory not empty

Информация о версии

Инструменты, которые я использую:

  • MSBuild 14.0
  • CMake 3.5.2
  • TeamCity Professional 9.1.7

Ответы [ 2 ]

0 голосов
/ 04 февраля 2019

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

https://visualstudio.microsoft.com/team-services/support/build-troubleshooting-guidance/

MSBuild и / nodeReuse: false

Если вы вызываете MSBuild во время сборки, обязательно передайте аргумент / nodeReuse: false (краткая форма / nr: false). В противном случае процесс (ы) MSBuild останется запущенным после завершения сборки. Процесс (ы) остаются в течение некоторого времени в ожидании потенциальной последующей сборки.

Эта функция MSBuild может мешать попыткам удалить или переместить каталог - из-за конфликта с рабочим каталогом процесса (ов) MSBuild.

Задачи MSBuild и Visual Studio Build уже добавляют / nr: false к аргументам, передаваемым в MSBuild. Однако, если вы вызываете MSBuild из своего собственного сценария, вам потребуется указать аргумент.

? (что, если на самом деле правильное лечение здесь, было бы гораздо более точное обращение, чем обходной путь неопределенности необходимости случайного уничтожения случайных не принадлежащих процессов в случайное время)

Обратите внимание, что если это коренная причина, то это может потребоваться исправить в исходном коде генератора CMake (вызов msbuild [, условно / интеллектуально]), тоже ...

Дополнительное примечание: я рассматриваю механизм поддержания фонового процесса для - задохнись! - цели телеметрии довольно неточными / неконтролируемыми образом (занятие каталогов, ...), и это для предположительно точно контролируемой / -исполненной / -детерминированной обработки сборки, довольно сомнительная [/ offensive] вещь.

0 голосов
/ 03 июля 2018

Что такое .tlog файлы?

Они выводятся MSBuild File Tracker, который оборачивает исполняемые файлы сборки Visual C ++ (например, cl.exe и link.exe), чтобы отслеживать, какие файлы он записывает и читает из них. Он записывает эти пути к файлам в файлах .tlog в промежуточном каталоге и использует их для определения способа построения инкрементной сборки.

(Источник: Внутри Microsoft Build Engine: использование MSBuild и Team Foundation Build , автор Сайед Хашими и Уильям Варфоломей.)

Что вызывает их создание?

Любое использование MSBuild может инициировать создание или обновление .tlog файлов.

Почему эти файлы появляются так поздно?

Один из процессов, записывающих файлы .tlog, - vctip.exe. В марте 2018 года инженер Microsoft Ян Бирман (владелец телеметрии для VC ++) объяснил :

Это небольшое приложение является фоновым процессом, который запускается во время сборки и позволяет инструментам VC ++ взаимодействовать со службой VS Telemetry (также известной как программа улучшения качества VS). Приложение продолжает работать после сборки, если сразу же запускается другая сборка, чтобы ускорить компиляцию.

Я понимаю, что текущее время ожидания (около 15 минут) слишком велико.

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

Как мне решить эту проблему?

Bearman предлагает два решения :

  1. Обновление Visual Studio.

    Предстоящие выпуски Visual Studio (начиная с VS 2017 15.7, теперь в предварительном просмотре) сократят время, в течение которого он продолжает работать, до 15 секунд после последней сборки. Надеюсь, что это решит все проблемы, которые у вас возникли с этой программой.

(Я не пытался выполнить обновление, поэтому я не могу подтвердить, что это решает проблему. Я также с интересом отмечаю более раннее сообщение об ошибке почти такой же проблемы, на которое был дан ответ обещание в марте 2018 года , что недавнее обновление устранило проблему.)

  1. Убить вручную vctip.exe.

Тем временем, чтобы обойти эту проблему, не стесняйтесь вручную убивать vctip.exe в любое время. Вы можете использовать команду Windows taskkill /IM vctip.exe, чтобы немедленно остановить ее. Это всегда безопасно делать, не опасаясь потери или повреждения данных.

В моем конкретном случае TeamCity это легко добавить в качестве дополнительного шага сборки к вашей конфигурации сборки после завершения MSBuild - запустив сценарий:

taskkill /IM vctip.exe /f >nul 2>&1

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...