У меня есть настройка SCons, которая буквально занимает часы при работе в чистом репозитории и выполняет ряд несвязанных задач, но при этом должна быть намного быстрее при выполнении с шагом. Сервер сборки убивает SCons через час, предполагая устаревшую сборку. Это нормально для меня, так как он будет периодически перезагружаться и, в конечном счете, сходиться в полное состояние.Flush. Периодически переписывать на диск
Однако это основано на предположении, что после убийства SCons я могу просто вернуться туда, где он был убит, и потерять, по большей части, задачу, над которой он работал в тот момент. Но после такого события файл .sconsign.dblite по-прежнему имеет нулевой размер, все цели отмечены как нетоковые и нестрочные (хотя они фактически существуют на диске), и при перезапуске сборки он делает это с нуля.
Я не нашел никаких документов, кроме некоторых летних дискуссий на эту тему ...
Что такое предполагаемое поведение и его можно настроить?
Это работает на Windows Server с использованием Jenkins, который говорит, что использует API-интерфейс TerminateProcess(). Я чувствую, что он иногда ведет себя так, как я ожидал, но я видел в одном случае, где этого не произошло. – mbschenkel
Когда Дженкинс использует TerminateProcess(), это совпадение, что вы видите желаемое поведение вообще. См. Https://msdn.microsoft.com/en-us/library/ms686722%28VS.85%29, где говорится: «Если процесс завершается TerminateProcess, все потоки процесса немедленно прекращаются без каких-либо запустите дополнительный код. Это означает, что поток не выполняет код в блоках обработчика завершения ». – dirkbaechle
В этом случае вопрос действительно сводится к тому, как я могу заставить SCons периодически записывать файл на диск. – mbschenkel