Как обойти параллельные процессы MSBuild, терпящие неудачу, потому что они касаются тех же файлов? - PullRequest
0 голосов
/ 21 марта 2020

У меня настроена сборка CMake для компиляции на разных платформах, и она прекрасно работает, за исключением одного небольшого лакомого кусочка: я не могу запустить ctest с опцией "jobs", например, -j8 для параллельного запуска тестов.

Я недавно выяснил, что это вызвано тем, что мои отдельные тесты действительно запускают cmake --build . --target the_current_test_executable, где каждый тест имеет свой собственный исполняемый файл. Я считаю, что параллельные задания в прогоне CTest порождают несколько процессов msbuild, каждый из которых пытается коснуться нескольких файлов маркеров. Я вижу этот тип ошибки:

C: \ Program Files (x86) \ Microsoft Visual Studio \ 2019 \ Community \ MSBuild \ Microsoft \ VC \ v160 \ Microsoft.CppBuild.targets (325 , 5): ошибка MSB3491: не удалось записать строки в файл "x64 \ Debug \ ZERO_CHECK \ ZERO_CHECK.tlog \ ZERO_CHECK.lastbuildstate". Процесс не может получить доступ к файлу 'C: \ somethingsomething \ x64 \ Debug \ ZERO_CHECK \ ZERO_CHECK.tlog \ ZERO_CHECK.lastbuildstate', поскольку он используется другим процессом. [C: \ somethingsomething \ ZERO_CHECK.vcxproj]

Я бы предпочел сохранить свои тесты такими, чтобы они создавали свой исполняемый файл при выполнении теста (для меня это простой способ % уверены, что они обновлены в процессе разработки). Но это мешает мне запускать их параллельно, только для сборки на основе Visual Studio. Обратите внимание, что все другие платформы и конфигурации (даже на Windows), использующие Ninja, могут справиться с этим очень хорошо.

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

...