Советы по организации исходников и сборок в разработке на C ++ под Linux (CMake as generator)

Question

Может кто-нибудь предложить несколько хороших методов для организации ваших исходных файлов и управления сборками при использовании C ++ под Linux. Я использую CMake для управления своими сборками, хотя в данный момент я не использую сложные конструкции. Допустим, у нас есть следующие три сценария.
1. Для приложения makefile просто собрать несколько исполняемых файлов из простых файлов .cpp и .h
2. Для создания статической / разделяемой библиотеки, которая использует другие популярные разделяемые библиотеки, скажем OpenCV и OpenGL, например.
3. Например, более сложные типы, скажем, нам нужно создать исполняемый файл, исходные файлы используют внешние библиотеки, такие как OpenCV, а также пользовательскую статическую библиотеку, которую мы создали сами (например, пользовательскую статическую библиотеку со связанными заголовками, которые мы построено с шагом 2 выше).

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

Answer 1

Поскольку вы используете CMake, я бы предложил использовать сборки вне исходного кода (либо полностью вне, либо в подкаталоге build корневого каталога проекта). При использовании более чем одной конфигурации и / или компилятора одновременно вы можете создатьотдельный каталог для каждой сборки.

В CMakeLists.txt в корневом каталоге проекта я установил материал, который будет использоваться всеми файлами CMakeLists.txt в подкаталоге src.Я помещаю все исходные файлы для исполняемых файлов и библиотек в подкаталог src и обычно группирую источники, которые образуют единую библиотеку или исполняемый файл, внутри их собственного подкаталога в src вместе с сопровождающим CMakeLists.txt, который описывает, как его создать.,Я обычно не отделяю включаемые файлы от источников.

У меня также есть подкаталог cmake в корневом каталоге проекта, куда я помещаю файлы, специфичные для CMake, такие как модули поиска, и в моем случае специальный модуль cmake, который исправляет пути, которые автоматически открывает Eclipse IDE.

|--cmake
|  |
|  |--FindXXX.cmake
|
|--src
|  |
|  |--projectABC
|  |  |
|  |  |--CMakeLists.txt
|  |
|  |--library1
|  |  |
|  |  |--CMakeLists.txt
|  |
|  |--library2
|     |
|     |--CMakeLists.txt
|
|--CMakeLists.txt
|
|--build-release
|--build-debug
|--build-msvc-release
|--[...]

Answer 2

Я предлагаю организовать источники по темам и иметь отдельные бинарные (или объектные) каталоги.Заголовочные файлы и исходные файлы в одном каталоге.Один каталог для каждого отдельного компилятора или платформы:

Fields
 |-- src
 |   field_int.hpp
 |   field_int.cpp
 |
 |-- obj_linux_gcc
 |   |
 |   |-- debug
 |   |
 |   |-- release
 |   
 |-- obj_windows_gcc
 |
 |-- obj_visual_studio

В последние годы в различных магазинах я обнаружил, что разделение заголовочных и исходных файлов на отдельные каталоги, независимо от темы, является сложной задачей, а такжезнакомство занимает много времени.

«Это только мое мнение, я могу ошибаться».- Денис Миллер, комик.