Russian Qt Forum
Октябрь 18, 2017, 19:39 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Организация больших проектов  (Прочитано 1290 раз)
sergek
Программист
*****
Offline Offline

Сообщений: 500


Мы должны приносить пользу людям!


Просмотр профиля
« : Апрель 20, 2017, 18:07 »

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

Qt 5.9.1 Qt Creator 4.4.1
Win7, Win10, Ubuntu 14.04
titan83
Самовар
**
Offline Offline

Сообщений: 185


Просмотр профиля
« Ответ #1 : Апрель 20, 2017, 18:23 »

Тоже интересно.
Может корифеи вкратце изложат... Строит глазки
Записан
ViTech
Крякер
****
Offline Offline

Сообщений: 362



Просмотр профиля
« Ответ #2 : Апрель 20, 2017, 18:32 »

Такая вот тема была: Управление структурой проекта (.pro).

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

Пока сам не сделаешь...
qate
Супер активный житель
*****
Offline Offline

Сообщений: 726


Просмотр профиля
« Ответ #3 : Апрель 20, 2017, 19:07 »

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

Сообщений: 500


Мы должны приносить пользу людям!


Просмотр профиля
« Ответ #4 : Апрель 20, 2017, 19:11 »

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

Qt 5.9.1 Qt Creator 4.4.1
Win7, Win10, Ubuntu 14.04
ViTech
Крякер
****
Offline Offline

Сообщений: 362



Просмотр профиля
« Ответ #5 : Апрель 20, 2017, 20:14 »

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

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

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

Код
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 и подключаются. Т.е. исходные файлы каждой библиотеки/приложения находятся в своём отдельном репозитории, а вместе собираются в качестве подмодулей в репозитории комплекса.  Пример такого комплекса приводился здесь. В каталоге project комплекса так же находятся проектные файлы систем сборки, которые управляют уже сборкой всего комплекса.

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

Пока сам не сделаешь...
sergek
Программист
*****
Offline Offline

Сообщений: 500


Мы должны приносить пользу людям!


Просмотр профиля
« Ответ #6 : Апрель 20, 2017, 21:49 »

Основной смысл отдельного каталога Build - его можно целиком грохнуть, не боясь зацепить что-то полезное.
Где располагаются ini-файлы приложения, js-скрипты и т.д.? Обычно их расположение задается относительно каталога запуска.
Т.е. исходные файлы каждой библиотеки/приложения находятся в своём отдельном репозитории, а вместе собираются в качестве подмодулей в репозитории комплекса.
Если у приложений есть общие модули, как организуется их совместное использование? К сожалению, не понял.
Не задумывался раньше - а что происходит с компиляцией совместных используемых файлов при сборке нескольких приложений?
« Последнее редактирование: Апрель 20, 2017, 23:57 от sergek » Записан

Qt 5.9.1 Qt Creator 4.4.1
Win7, Win10, Ubuntu 14.04
ViTech
Крякер
****
Offline Offline

Сообщений: 362



Просмотр профиля
« Ответ #7 : Апрель 20, 2017, 23:26 »

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

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

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

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

Пока сам не сделаешь...
sergek
Программист
*****
Offline Offline

Сообщений: 500


Мы должны приносить пользу людям!


Просмотр профиля
« Ответ #8 : Апрель 21, 2017, 00:13 »

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

Qt 5.9.1 Qt Creator 4.4.1
Win7, Win10, Ubuntu 14.04
deMax
Бывалый
*****
Offline Offline

Сообщений: 486



Просмотр профиля
« Ответ #9 : Апрель 21, 2017, 11:11 »

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

Сообщений: 500


Мы должны приносить пользу людям!


Просмотр профиля
« Ответ #10 : Апрель 21, 2017, 11:58 »

Да еще бы CI воткнуть Улыбающийся ну чтоб на сервере проверялось, в git результаты тестов дописывало и в редмайне отображало.
Ничего не понял Подмигивающий
Записан

Qt 5.9.1 Qt Creator 4.4.1
Win7, Win10, Ubuntu 14.04
deMax
Бывалый
*****
Offline Offline

Сообщений: 486



Просмотр профиля
« Ответ #11 : Апрель 21, 2017, 12:09 »

Ничего не понял Подмигивающий
CI - continuous integration.
Записан
ViTech
Крякер
****
Offline Offline

Сообщений: 362



Просмотр профиля
« Ответ #12 : Апрель 21, 2017, 12:53 »

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

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

Именно, как правило. Но не всегда. Но и это не главное, а то, что на этапе разработки эти модули активно дорабатываются и смысла их линковать нет.

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

А если есть тесты и модульность? Да еще бы CI воткнуть Улыбающийся ну чтоб на сервере проверялось, в git результаты тестов дописывало и в редмайне отображало.

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

Пока сам не сделаешь...
sergek
Программист
*****
Offline Offline

Сообщений: 500


Мы должны приносить пользу людям!


Просмотр профиля
« Ответ #13 : Апрель 21, 2017, 13:22 »

Это проблемы системы сборки, а не организации структуры проекта.
Пожалуй, вы правы.
Записан

Qt 5.9.1 Qt Creator 4.4.1
Win7, Win10, Ubuntu 14.04
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  

Страница сгенерирована за 0.094 секунд. Запросов: 22.