Russian Qt Forum

Коллеги,
мне казалось, здесь появлялась тема о принципах организации больших проектов (несколько подпроектов, совместное использование исходников и др.).
Может, напомните, где это обсуждалось?

Тоже интересно.
Может корифеи вкратце изложат... ::)

Такая вот тема была: Управление структурой проекта (.pro) (http://www.prog.org.ru/topic_30171_0.html).

А что конкретнее интересует и с чем проблемы возникают?

да, тоже интересно, как организовать проект, чтобы если гдето чтото починил, то в другом месте не поломалось ?

Спасибо.
Примерно это и интересует - в какой мере иерархия проекта стремится к иерархии разрабатываемой системы.
 

Я в ходе своей деятельности пришёл к следующему положению вещей :).

На глобальном уровне:

Отделять "исходные файлы проекта" от всего остального. Быстрый пример:

C++ (Qt)
+ ProjectA
+ ProjectB
+ Build
| + ProjectA
| + ProjectB
+ Workdir
| + ProjectA
| + ProjectB
 

В Project* располагаются "исходные файлы проекта" (подробнее ниже).

В Build происходит сборка проекта, там весь сборочный мусор и его результат - исполняемые файлы. Каталог с исполняемыми файлами (пусть будет bin) можно вынести и на уровень выше (наравне с Build). Это может быть актуально для qmake. Но я пользуюсь в основном Qbs, и он сам складывает все исполняемые файлы крупного проекта в одно место. Основной смысл отдельного каталога Build - его можно целиком грохнуть, не боясь зацепить что-то полезное.

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

Возможно ещё какие-нибудь каталоги понадобятся на таком высоком уровне: Tool, Script и т.п.

На уровне "исходных файлов проекта":

Этот каталог должен быть подготовлен к существованию под управлением системы контроля версий. Я пользуюсь git, с остальными будет аналогично. Здесь должны располагаться только необходимые файлы для совместной разработки: сами исходные файлы, необходимые для сборки ресурсы, проектные файлы для систем сборки, тесты и тому подобное.

Рядом с проектными файлами для систем сборки наверняка будут создаваться проектные файлы IDE, как полезные, так и временные.  QtCreator создаёт *.user. Visual Studio гадит намного больше. Все эти файлы от IDE нужно добавлять в список игнорирования git, для совместной разработки они не нужны.

Структура файлов отдельного модуля (библиотеки/приложения) может быть разной. К примеру такой:

C++ (Qt)
+ include
| + LibraryName
|   | *.h 
+ project
| + doxygen
| + qbs
| + qmake
| + cmake
+ src
| | *.h, *.cpp, *.ui, *.res, etc.
+ test
| | unit-test, etc.
 

На уровне "комплекса":

Комплекс состоит из множества модулей (библиотек/приложений). В терминах git модуль - это submodule, а комплекс - коневой репозиторий, к которому эти submodule и подключаются. Т.е. исходные файлы каждой библиотеки/приложения находятся в своём отдельном репозитории, а вместе собираются в качестве подмодулей в репозитории комплекса.  Пример такого комплекса приводился здесь (http://www.prog.org.ru/index.php?topic=30171.msg222516#msg222516). В каталоге project комплекса так же находятся проектные файлы систем сборки, которые управляют уже сборкой всего комплекса.

В общих чертах как-то так :). Если нужны подробности по какому-то пункту - спрашивайте.

Где располагаются ini-файлы приложения, js-скрипты и т.д.? Обычно их расположение задается относительно каталога запуска.
Если у приложений есть общие модули, как организуется их совместное использование? К сожалению, не понял.
Не задумывался раньше - а что происходит с компиляцией совместных используемых файлов при сборке нескольких приложений?

Нормальное приложение должно работать относительно рабочего каталога (https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B1%D0%BE%D1%87%D0%B8%D0%B9_%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3), который указывается при его запуске. В предлагаемой схеме это Workdir, там отдельная папка для каждого приложения. Это для примера, основной смысл в том, чтобы рабочий каталог располагался отдельно от Build, bin и исходников.


Совместно используемый модуль - это, как правило, библиотека, которая может быть собрана как динамической, так и статической. Т.е., по-хорошему, совместно используемые файлы должны формироваться в библиотеку и компилироваться только в ней (*.cpp). Такую собранную библиотеку затем могут линковать модули, в которых она требуется. Заголовочные файлы *.h библиотеки должны быть доступны другим модулям, через подключение по системным путям вида #include <LibraryName/SomeHeader.h>. Система сборки сама должна отслеживать зависимости между модулями и собирать их в таком порядке, чтобы не возникало неразрешённых зависимостей.

Каталог запуска, рабочий каталог - не суть. Где же располагаются упомянутые мной файлы, отдельно от проекта, в каталоге, который грохнуть?
Именно, как правило. Но не всегда. Но и это не главное, а то, что на этапе разработки эти модули активно дорабатываются и смысла их линковать нет.
Но ваш подход понятен, спасибо за советы.

А если есть тесты и модульность? Да еще бы CI воткнуть :) ну чтоб на сервере проверялось, в git результаты тестов дописывало и в редмайне отображало.
Имхо для build-а и так теневая папка создается отдельно(где её создавать и как можно прописать, но обычно и по умолчанию нормально).
Мое имхо как то так(для одного проекта):
bin
test - здесь папки с тестами
src
modules - здесь папки с модулями

Ничего не понял ;)

CI - continuous integration.

Упомянутые файлы располагаются в каталоге Workdir, отдельно от каталога с проектом под управлением git. Если есть общие *.ini, *.js и прочее, то можно их тоже добавить под управление git, и копировать в тот Workdir. Это уже больше относится к стадии развёртывания приложения и настройки его окружения. Лично я предпочитаю, чтобы в git было минимум мусора, который может появляться на этапе сборки, развёртывания и работы продукта.


Не вижу тут особых проблем или противоречий. Изменились файлы библиотеки - она пересобралась и следом все зависящие от неё модули, если эти изменения их затронули. Это проблемы системы сборки, а не организации структуры проекта.


Кто дошёл до CI, тот, скорей всего, свою структуру проектов уже придумал :). Я больше про рабочее место разработчика рассказываю.

Пожалуй, вы правы.