//=======================================================================================
VLibs -- репозиторий решений на плюсах, собранных в виде микрокомпонент.
//=======================================================================================
Авторы:
Саша Громцев aka elapidae
Надя Чурикова aka claorisel
Ваня Дейлид aka sid1057
Катя Болтенкова aka kataretta
В каждом компоненте планируется размещать свое описание, здесь только общие сведения.
Каждый компонент обеспечивает решение, либо помогающий в решении какой-либо задачи.
Компоненты объединяет общий подход в использовании, подключении к проектам QMake и CMake.
Весь код поставляется как есть, никакие исходники собирать не надо, а надо подключать
нужные компоненты, непосредственно, к системе сборки проекта QMake / CMake.
Тонкостей и вопросов много, это "затравочное" описание, которое следует развивать
по мере возможностей, вопросы и замечания очень приветствуются.
TODO: описание префикса "v"
TODO: отношение к namespace-ам
TODO: подробнее о qmake & cmake --> *.pro & *.cmake
TODO: тесты
TODO: code guideline
TODO: описание работы с git, точнее с subrep-ами
//=======================================================================================
Чтобы подключить компонент <vcomponent> нужно:
1. Скачать репозиторий.
2. Прописать в файле проекта строчки:
Для cmake:
set( VLIBS_DIR "path_to/vlibs" )
include( "${VLIBS_DIR}/vcomponent/vcomponent.cmake" )
Для qmake:
VLIBS_DIR = $$PWD/path_to/vlibs
include( $$VLIBS_DIR/vcomponent/vcomponent.pri )
3. Пользоваться:
#include "vcomponent.h"
VComponent c;
c.use(); // :-).
//=======================================================================================
Объяснение позиции автора к такому подходу в стиле Question-Answer:
//-----------------------------------------------------------------------------------
Q1: Почему надо тянуть всю vlibs, если мне из нее надо только маленький кусочек?
A: Сама vlibs есть некоторый аналог coreutils, только для плюсов.
Это есть набор микроинструментов, которые применяются от проекта к проекту.
Притом в каждом проекте могут применяться 5-10% из всего что в vlibs находится.
Дело в том, что эти %% для каждого проекта РАЗНЫЕ.
Есть микрухи, которые используются в каждом проекте. Вот, нажал menu->new project,
сразу подключил vlibs->vlog, сразу пишу в main() 'vdebug << "Hello world!"'.
Да, кстати, никто не жалуется, зачем ему, например, весь STL, если нужен только
std::vector...
//-----------------------------------------------------------------------------------
Q2: Я хочу использовать только свои 10%, остальное мне НЕ НУЖНО!
A: Не подключай остальное к проекту. Оно не попадет в сборку.
Можно только пенять на занятое место, учитывая вес vlibs, даже не смешно.
Преимущества автоподключения -- подключается ТОЛЬКО нужные микрухи.
В случае с библиотекой такое не прокатит: либо вот тебе всю, либо иди гуляй.
//-----------------------------------------------------------------------------------
Q3: А давай разобьем эти микрухи на отдельные кусочки (микрорепозитории?).
A: Вся прелесть этих микрух, что они могут использовать друг друга.
*.cmake и *.pri файлики устроены таким образом, чтобы части, которые используют
другие микрухи подцепляли их автоматически. Если их разложить "далеко" друг от друга,
то их стыковка будет сложнее для конечного программиста. Например, базовая часть vlog
использует специальный интерфейс (vcat_iface), входящий в отдельную микруху (vcat).
Кроме него этот интерфейс еще используется двумя другими микрухами. Соотв. если
добавить к этому интерфейсу какой-нибудь метод (например, модификатор потока), то его
сразу же получат все три компонента. Преимущества можно оценить поработав с такой
системой микросервисов.
Ничего более удобного автор близко ни в какой другой системе сборки для C++ не видел.
//-----------------------------------------------------------------------------------
Q4: Что значит подключают другие микросервисы автоматически?
A: Микросервисы привязывают себя к системе сборки через переменную VLIBS_DIR,
соответственно, они могут подключать нужные им другие компоненты рекурсивно.
Притом, зависимости сразу видны (по крайней мере, в QtCreator). Таким образом,
сразу видна архитектура и зависимости. Проекты, без зависимостей находятся на
"нулевом этаже" и зависят только от стандартной библиотеки[*], использующие такие
компоненты оказываются на "первом этаже" и т.д. Иерархия применения компонент
выстраивается автоматически, циклические зависимости сразу же фиксируются сборкой.
[*] Есть компоненты-обертки к подключению системных библиотек. В их задачу, в т.ч.
входит мягкое "всасывание" в проект библиотеки, настройка путей к заголовкам,
включение pkg-config-а и пр. В общем, помощь в использовании библиотеки.
Опять же, сразу видно какие библиотеки используются.
//-----------------------------------------------------------------------------------
Q5: Ну ладно, пусть лежат, но мне не нравиться, что оно собирается каждый раз с
новым проектом, я хочу чтобы это было библиотека!
A1: Нажимаем "new project -> library", подключаем все микрухи, собираем БИБЛИОТЕКУ!
Ну правда, когда есть исходники, собрать библиотеку можно, обратное не верно.
A2: Речь о заботе о конечном пользователе. Проследим путь работы с библиотекой:
1. скачать (git clone ssh://green_wolf.com/git);
2. насторить и скомпилировать (./configure, make);
3. зас*ать собственную систему из под рута (sudo make install,
для умных: sudo checkinstall);
4. подключить к проекту (в .pro LIBS += -lgreen_wolf -L/opt/green_wolf/lib,
в cmake: REQUIRED..., притом, надо, чтобы библиотека себя еще и подготовила
для REQUIRED). Настроить пути, если не стандартны. Если библиотека требует,
использовать pkg-config и прочие радости.
Притом, каждый библиотекописарь сам себе агроном и творит такое, что подключение
библиотеки может превратиться в длииииннное приключение (Кстати, именно поэтому,
библиотеки тоже подключаются через механизм vlibs. Один раз на***ся, перелопатил пол
инета, зато потом можно забыть как страшный сон).
Т.е. имеем цикл:
{ git clone ->
configure ->
make ->
sudo install ->
// должна быть фиксация версии в проекте, но ее нету...
}
Что предлагается:
{
git ->
фиксация в проекте.
}
Где простота и надежность -- решать вам...
При изменении библиотеки, все с самого начала. Хотим поменять флаг компиляции
библиотеки ... ну ты понел? Далее -- имеем несовместимые версии библиотек на разных
машинах (Сталкивались с этим? А автор стакивался, когда разобрался, к компу неделю
не подходил). Это потому что используемые библиотеки не зафиксированы с исходниках.
В случае использования механизма vlibs, имеем две ОЧЕВИДНЫЕ строчки для подключения
нужного компонента, остальные тихо-мирно лежат рядышком, ждут своей очереди.
Подключаем субрепом -- никаких проблем с запуском на других машинах[*].
Есть еще ряд преимуществ, не сразу видных со стороны. Например, если собираемся из
исходников, то помогаем компилятору с оптимизацией.
[*] Про внешние библиотеки речи нету, здесь никак не помочь, с ними весь этот АДъ.
Речь о том, что, хотя бы, наш код будет под контролем git.
//=======================================================================================