Сборка CMake + Ninja не распараллеливается между библиотеками
У нас есть (C ++) программа, которая настроена как серия общих библиотек с вложенной иерархией. То есть libB.so использует функции из и, следовательно, ссылается на libA.so, libC.so использует функции и ссылается как на libB.so, так и на libA.so и т. Д.
Для нашей текущей системы сборки CMake + Ninja я заметил, что параллельное построение, похоже, не происходит между библиотеками. То есть, в то время как Ninja обычно использует 12 ядер для сборки, если я коснулся одного исходного файла из libA, но нескольких в libC, ninja будет использовать только один процессор для сборки только исходного файла libA, пока liba.so не будет связан, в этот момент он будет использовать 12 процессоров для компиляции исходных файлов libC. — И если в исходном коде libA есть ошибка компиляции, он даже не попытается скомпилировать файлы libC в объектные файлы, даже если я передам -k для ninja.
Конечно, связывание libC.so необходимо отложить до связывания libA.so, но компиляция исходных файлов в объектные файлы для источников libC не должна задерживаться для связывания libA.
Я что-то упускаю из-за оптимального способа настройки наших файлов CMake для выражения зависимостей между библиотеками? Или это непреодолимое ограничение того, как работает ниндзя?
Решение
Об этом недавно спросили в списке рассылки CMake. ответ от одного из разработчиков подтверждает, что поведение, о котором вы сообщаете, является преднамеренным:
К сожалению, это необходимо для получения правильных сборок для проектов CMake.
в общем, потому что мы поддерживаем случаи, когда используется add_custom_command
в библиотеке «foo» для создания заголовочного файла, который включается во время
компиляция в библиотеке «bar», которая ссылается на «foo», но у нас нет ничего хорошего
способ выразить эту зависимость помимо упорядочения зависимости бара
на фу.
Хотя может быть возможно улучшить CMake, чтобы ослабить это ограничение в некоторых обстоятельствах, похоже, что это еще не было сделано (по состоянию на CMake 3.6). Там есть открытый билет для этого в трекере проблем Kitware уже.
Обновить: Похоже, это было исправлено в CMake 3.9.0, хотя это изменение привело к регрессии, которая затем была исправлено в 3.12.0, или же возможно 3.11.2.
Другие решения
Других решений пока нет …