Ответ 1
Проект логически группирует несколько целей (то есть библиотеки, исполняемые файлы и пользовательские шаги сборки) в самостоятельную коллекцию, которая может быть построена сама по себе.
На практике это означает, что если у вас есть команда project в CMakeLists.txt, вы должны иметь возможность запускать CMake из этого файла, а генератор должен создавать что-то, что можно построить. В большинстве кодовых баз у вас будет только один проект для каждой сборки.
Обратите внимание, что вы можете вложить несколько проектов. Проект верхнего уровня может включать в себя подкаталог, который, в свою очередь, является другим автономным проектом. В этом случае команда project вводит дополнительные области для определенных значений. Например, переменная PROJECT_BINARY_DIR всегда будет указывать на корневую двоичную директорию текущего проекта. Сравните это с CMAKE_BINARY_DIR, который всегда указывает на двоичную директорию проекта верхнего уровня. Также обратите внимание, что некоторые генераторы могут генерировать дополнительные файлы для проектов. Например, генераторы Visual Studio создадут файл решения .sln для каждого подпроекта.
Используйте подпроекты, если ваша кодовая база очень сложна, и вам нужно, чтобы пользователи могли изолировать отдельные компоненты. Это дает вам очень мощный механизм структурирования системы сборки. Из-за повышенных требований к кодированию и обслуживанию, необходимых для того, чтобы сделать несколько подпроектов действительно самодостаточными, я бы посоветовал только спуститься по этой дороге, если у вас есть реальный прецедент для этого. Разделение кодовой базы на разные цели всегда должно быть предпочтительным механизмом структурирования сборки, тогда как подпроекты должны быть зарезервированы для тех редких случаев, когда вам действительно нужно сделать подмножество целей автономными.