Структура приложения

Меня уже давно интересует как правильно организовать структуру приложения(набор каталогов, файлов etc). Куда класть сторонние библиотеки и в какой форме? Если исходники, то это надо файлы лицензий, документацию, писать какие-то скрипты для сборки. Или просто оставлять список зависимостей, которые надо скачать/собрать/установить? Но ведь это выглядит не очень удобно. Может есть какие-то методы работы с 3rd party проектами?
P.S. Использую систему сборки cmake.

0

Сообщение от ВАСИЛЕВС P.S. Использую систему сборки cmake.

у меня кроссплатформенная система,
которая ориентированна на поддержку крупных и малых проектов,
в условиях независимости от целевых IDE.

сегодня базируется на "умных" сценариях сборки под управлением cmake.


есть иерархия каталогов:

в деплое содержатся исходный код чужих библиотек,
которые нужно собирать из исходников.
такие, как например boost, gmock, tools, etc

все они организуются по единой схеме:
при необходимости скрипты сборки и исходный код пропатчивается,
затем жмутся архиватором 7z.
есть скрипты, которые имеют одинаковые имена:

виндовсы:
make.bat

линуксы:
make.sh

цель простая:
сотрудник компании не должен мудохаться со сборкой.
для разворота какого нибудь boost необходимо зайти в его каталог,
и запустить батник.

собранный буст попадает в каталог external.

выглядит это примерно так:

вот здесь имена каталогов: mingw/gcc/msvc2013 выступают в качестве тэгов конфигурации
в зависимости от конфигурации сборки, умный сценарий самостоятельно опредилит,
куда именно можно заходить, а куда нельзя.
и сможет найти библиотеку.

рассмотрим каталог чуть поближе:

сами по себе библиотеки могут располагаться по каким угодно путям,
и иметь самое разнообразное строение.

однако, в именах каталогов или файлов так же могут содержаться тэги конфигурации.

в данном случае по циферкам 32/64 умный сценарий сможет различать адрессную модель
(32 или 64 битная сборка)
а по таким тэгам, как debug, или -d может отличить дебажную либу от релизной.

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

обыкновенно, в каталоге projects содержится CMakeLists.txt
это - умный сценарий. он один единственный на все рабочее пространство.
не нужно знать что внутри него, и вообще для работы знания cmake не понадобится.

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

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

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


так же, в каталоге содержатся батники, задача которых - запустить cmake.
(мне лень в командной строке вводить команду запуска.
я работаю из Far, или mc, и запускаю сборку одним нажатием на enter по батничку)

батник содержит три возможные настроки:
генерация файлов проекта целевой ИДЕ, и остановка
генерация файлов проекта целевой ИДЕ, и запуск этой ИДЕ
генерация файлов проекта целевой ИДЕ, и запуск сборки

очень удобно.

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

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

находит цели-демонстрации, если они есть.
находит цели-юнит-тесты, если они есть.
и подключает к ним все необходимое.

если есть зависимости от динамических либ - копирует их к бинарнику
если есть ресурсы (картинки, конфиги) - копирует их к бинарнику.

короче - полное обслуживание.

и на выхлопе формируется список всех обнаруженных целей.

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

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

это нужно, что бы все зависимости были удовлетворенны.

резюмируя:

придерживаясь нескольких весьма простых правил,
на cmake не сложно автоматизировать всю рутину.

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

2

Спасибо за схему каталогов, я как-то даже не подумал о такой форме. Получается, что вы смешиваете скрипты(sh, bat) + систему cmake? Можно подробнее о умных сценариях?

0