На ранней стадии нашей разработки мы создали микро-репозитории, чтобы иметь возможность глубоко изменять репозитории, сводя к минимуму взаимное влияние на работу друг друга. Теперь, когда у нас есть довольно стабильная версия нашей кодовой базы, мы хотим объединить некоторые из микро-репозиториев в монорепозиторий. Это упростит пользователям процесс сборки из исходного кода, а также на этапе развертывания.
Все наши микро-репозитории построены с помощью CMake, и каждый из них, очевидно, определяет project()
. У них также есть «внутренние» зависимости: некоторые из микро-репозиториев сначала создаются, а затем используются другими с помощью find_package()
.
RepoA
|-- CMakeLists.txt
| project(RepoA)
RepoB
|-- CMakeLists.txt
| project(RepoB)
| find_package(RepoA)
RepoC
|-- CMakeLists.txt
| project(RepoC)
| find_package(RepoA)
| find_package(RepoB)
При миграции их в монорепозиторий, первый вариант, который пришел я мысленно перемещаю каждый из них в подкаталог, а затем добавляю add_subdirectory()
в файл root CMakeLists.txt
для их создания. В первом случае я бы определил глобальный проект, используя project()
в файле root CMakeLists.txt
, и я бы также сохранил определение project()
в подкаталогах.
Monorepo/
|-- CMakeLists.txt
| project(Monorepo)
| add_subdirectory(RepoA)
| add_subdirectory(RepoB)
| add_subdirectory(RepoC)
|-- RepoA/
|-- CMakeLists.txt
| project(RepoA)
|-- RepoB/
|-- CMakeLists.txt
| project(RepoB)
| find_package(RepoA)
|-- RepoC/
|-- CMakeLists.txt
| project(RepoC)
| find_package(RepoA)
| find_package(RepoB)
Теперь вопрос: это хороший выбор? Вы бы посоветовали создать глобальный проект и несколько подпроектов, все из которых определены с помощью команды CMake project()
? Есть ли лучшие стратегии?
А также, будут ли у этой стратегии недостатки?
Большое спасибо за вашу помощь!