На самом деле я бы не назвал это проблемой, особенно для небольшого проекта. Если Вы ожидаете завершения сборки 30 секунд, то тут вряд ли можно существенно ускорить сборку.
Однако, если в проекте задействовано 20 библиотек и сборка производится на мощном многоядерном проце, то эффект будет куда больше.
CMake не выполняет параллельную сборку статических библиотек (по крайней мере в паре с make).Для примера из статьи CoherentDeps, вывод сборки будет следующим:
build-CoherentDeps-Desktop-Debug$ make -j4
Scanning dependencies of target staticA
[ 12%] Building CXX object staticA/CMakeFiles/staticA.dir/source_a.cpp.o
[ 25%] Linking CXX static library libstaticA.a
[ 25%] Built target staticA
Scanning dependencies of target staticB
[ 37%] Building CXX object staticB/CMakeFiles/staticB.dir/source_b.cpp.o
[ 50%] Linking CXX static library libstaticB.a
[ 50%] Built target staticB
Scanning dependencies of target staticC
[ 62%] Building CXX object staticC/CMakeFiles/staticC.dir/source_c.cpp.o
[ 75%] Linking CXX static library libstaticC.a
[ 75%] Built target staticC
Scanning dependencies of target CoherentDeps
[ 87%] Building CXX object CMakeFiles/CoherentDeps.dir/main.cpp.o
[100%] Linking CXX executable CoherentDeps
[100%] Built target CoherentDeps
Это говорит о последовательном выполнении этапов.
В то же время, для другого примера из статьи NonCoherentDeps, обработка статических бибилиотек выполняется параллельно:
build-NonCoherentDeps-Desktop-Debug$ make -j4
Scanning dependencies of target staticC
Scanning dependencies of target staticA
Scanning dependencies of target staticB
[ 25%] Building CXX object staticC/CMakeFiles/staticC.dir/source_c.cpp.o
[ 25%] Building CXX object staticA/CMakeFiles/staticA.dir/source_a.cpp.o
[ 37%] Building CXX object staticB/CMakeFiles/staticB.dir/source_b.cpp.o
[ 50%] Linking CXX static library libstaticC.a
[ 75%] Linking CXX static library libstaticA.a
[ 75%] Linking CXX static library libstaticB.a
[ 75%] Built target staticC
[ 75%] Built target staticB
[ 75%] Built target staticA
Scanning dependencies of target NonCoherentDeps
[ 87%] Building CXX object CMakeFiles/NonCoherentDeps.dir/main.cpp.o
[100%] Linking CXX executable NonCoherentDeps
[100%] Built target NonCoherentDeps
Данный подход увеличивает количество целей, которые могут быть собраны одновременно. Количество работы остается тем же, но, если используется машина с многоядерным процессором, можно полуить прирост за сяет распараллеливания сборки или более эффективно использовать распределенную сборку. Для make, разумеется, необходимо указывать специальные опции
Отличный подход. Просто, с большим проектом со множеством библиотек может возникнуть проблема, и избежать зависимостей не удасться.
Например, у нас используется очень разветвленная структура проекта, и путь к исходникам одной библиотеки может выглядеть вот так: project/sdks/utils/window-utils
Можно было бы использовать target_include_directories, или include_directories, но мы используем описанный в статье подход, так как он более удобен.
Кроме INTERFACE_INCLUDE_DIRECTORIES можно добавить к мета-пакету INTERFACE_COMPILE_DEFINITION и INTERFACE_COMPILE_OPTIONS. Никогда не видел использование этой возможности, но она есть.
Кроме того, у нас генерируются заголовочные файлы через configure для одних библиотек, которые потом используются в cpp-файлах в других. Так вот, можно выполнить слудующую последовательность шагов:
добавляем цель для генерации файла
через add_dependencies указываем, что мета-пакет зависит от цели генерации
необходимый заголовочный файл будет сгенерирован перед сборкой любых зависимых библиотек
Наверное стоило сразу очертить юзкейс. Я потихоньку пилю многопоточное приложение SecureDialogues. Некоторые сущности должны храниться на диске в зашифрованном виде. Между этими сущностями есть отношение один ко многим, в дочернем компоненте есть идентификатор родителя. Так же при удалении/обновлении/вставке объектов генерируется событие (вроде триггера), на которое подписаны другие компоненты.
Вторичные индексы я планирую использовать для того, чтобы:
при удалении объекта, извлекать из базы все его дочерние (по индексу родителя).
удалять их из БД
выкидывать сообщение об удалении каждого дочернего объекта.
Это важное замечание, и в статью добавлена информация о том, что ENTRYPOINT и CMD могут быть указаны вместе.
По поводу клонирования git-репозитория внутрь контейнера.
Такое поведение полезно, когда комиты попадают в мастер только через pull request (это позволяет выполнить, как минимум, сode review ). При таком подходе происходит разделение ролей — одни пишут код, другие выполняют сode review, а третьи выпускают версии (создают тег с новой версией в репозитрии и выполняют сборку релиза из добавленного тега). Клонирование репозитория с нужным тэгом внутрь контейнера, как минимум, упрощает сборку новой версии (не придется руками выполнять команду git checkout ...). Так же, такое поведение исключает вероятность того, что папка с исходниками может содержать незакомиченный код, ветку разработки и пр.
Использование сборки с volume так же описана в статье.
Нужно для начала определиться — для чего мы используем образ.
В данной статье образ используется только для сборки. Если есть приватный репозиторий, то данные для аутентификации могут быть проброшены в контейнер, например через параметры -e, --env, --env-file команды docker run.
Третий момент, который хочется подсветить — касается кэширования.
Это полезное добавление. Я упустил из виду возможность использовать COPY для копирования исходников внутрь контейнера.
Возможно кого-то это может запутать, именно на такой случай статья содержит большое количество ссылок на документацию к docker. Эти определения взяты оттуда же.
В моем примере предполагается, что среда разворачивается скриптом на локальном хосте для сборки релиза. А дальше, все дальнейшие изменения в среду вносятся руками, не скриптом. Т.е. в дальнейшей сборке приложения данный скрипт не участвует.
Можно было бы описать более интеллектуальный скрипт, который запускается при сборке, обновляет зависимости, удаляет все лишнее, но тогда пришлось бы менять название статьи.
Но процесс сборки производился на выделенном сервере с использованием скриптов.
А как это выглядело? Скрипт устанавливает необходимые библиотеки или просто запускает сборку? Просто у нас в компании так же используется сборка на выделенном сервере, но make-скрипты просто запускают саму сборку. Предполагается, что все зависимости уже были установлены заранее.
Необходимо сделать пояснение о назначении bash-скрипта в примере. Он разворачивает среду для сборки приложения, ставит нужные библиотеки и пр. Далее, в процессе разработки, программист устанавливает необходимые компоненты в уже развернутой среде и добавляет команды в указанный bash-скрипт. Забытая зависимость всплывет при повторном разворачивании всей среды.
docker-файл содержит аналогичные команды скрипту bash, но в отличии от него используется намного чаще, как минимум для сборки каждого релиза. Соответственно, пропущенная зависимость будет выявлена гораздо быстрее в этом случае.
На самом деле, Вы можете попробавать класс https://github.com/sqglobe/OpenGLWidget/blob/main/OpenGLWidget.h
По идее он должен работать и на винде тоже. Ечли понадобится, что-нибудь подтюнить, то это не сложно сделать
Круто! Но зачем страдать, пытаясь сделать что-на на "еще одном языке", когда все это уже нормально откатано и работает на С++?
разница в том, что у Вас пример использования GtkGLArea, а в статье речь про то, что у виджета 'под капотом'
На самом деле я бы не назвал это проблемой, особенно для небольшого проекта. Если Вы ожидаете завершения сборки 30 секунд, то тут вряд ли можно существенно ускорить сборку.
Однако, если в проекте задействовано 20 библиотек и сборка производится на мощном многоядерном проце, то эффект будет куда больше.
CMake не выполняет параллельную сборку статических библиотек (по крайней мере в паре с make).Для примера из статьи CoherentDeps, вывод сборки будет следующим:
Это говорит о последовательном выполнении этапов.
В то же время, для другого примера из статьи NonCoherentDeps, обработка статических бибилиотек выполняется параллельно:
Данный подход увеличивает количество целей, которые могут быть собраны одновременно. Количество работы остается тем же, но, если используется машина с многоядерным процессором, можно полуить прирост за сяет распараллеливания сборки или более эффективно использовать распределенную сборку. Для make, разумеется, необходимо указывать специальные опции
Отличный подход. Просто, с большим проектом со множеством библиотек может возникнуть проблема, и избежать зависимостей не удасться.
Например, у нас используется очень разветвленная структура проекта, и путь к исходникам одной библиотеки может выглядеть вот так: project/sdks/utils/window-utils
Можно было бы использовать
target_include_directories, илиinclude_directories, но мы используем описанный в статье подход, так как он более удобен.Кроме INTERFACE_INCLUDE_DIRECTORIES можно добавить к мета-пакету INTERFACE_COMPILE_DEFINITION и INTERFACE_COMPILE_OPTIONS. Никогда не видел использование этой возможности, но она есть.
Кроме того, у нас генерируются заголовочные файлы через configure для одних библиотек, которые потом используются в cpp-файлах в других. Так вот, можно выполнить слудующую последовательность шагов:
Спасибо за развернутый ответ. Буду сравнивать варианты
Наверное стоило сразу очертить юзкейс. Я потихоньку пилю многопоточное приложение SecureDialogues. Некоторые сущности должны храниться на диске в зашифрованном виде. Между этими сущностями есть отношение один ко многим, в дочернем компоненте есть идентификатор родителя. Так же при удалении/обновлении/вставке объектов генерируется событие (вроде триггера), на которое подписаны другие компоненты.
Вторичные индексы я планирую использовать для того, чтобы:
В принципе скорость работы не так уж важна.
а тарантул разве встраиваемый?
Какой key/value аналог BDB на С/С++ вы можете посоветовать для open source проекта?
Необходимо, чтобы поддерживались:
Можно взять за основу один из описанных вот тут — https://hub.docker.com/_/microsoft-windows-base-os-images
Пример Dockerfile с описанием windows-окружения есть вот тут — https://docs.microsoft.com/ru-ru/virtualization/windowscontainers/manage-docker/manage-windows-dockerfile
Не совсем так, в документации написано, что, кроме склеивания,
ENTRYPOINTможет полностью затиратьCMD— https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact.Это важное замечание, и в статью добавлена информация о том, что
ENTRYPOINTиCMDмогут быть указаны вместе.По поводу клонирования git-репозитория внутрь контейнера.
Такое поведение полезно, когда комиты попадают в мастер только через pull request (это позволяет выполнить, как минимум, сode review ). При таком подходе происходит разделение ролей — одни пишут код, другие выполняют сode review, а третьи выпускают версии (создают тег с новой версией в репозитрии и выполняют сборку релиза из добавленного тега). Клонирование репозитория с нужным тэгом внутрь контейнера, как минимум, упрощает сборку новой версии (не придется руками выполнять команду
git checkout ...). Так же, такое поведение исключает вероятность того, что папка с исходниками может содержать незакомиченный код, ветку разработки и пр.Использование сборки с volume так же описана в статье.
В данной статье образ используется только для сборки. Если есть приватный репозиторий, то данные для аутентификации могут быть проброшены в контейнер, например через параметры
-e, --env, --env-fileкомандыdocker run.Это полезное добавление. Я упустил из виду возможность использовать
COPYдля копирования исходников внутрь контейнера.Возможно кого-то это может запутать, именно на такой случай статья содержит большое количество ссылок на документацию к docker. Эти определения взяты оттуда же.
Да, это хороший вариант дальнейшего развития
В статье была допущена ошибка в имени кросс-компилятора. Правильное название — mingw-w64
Вы совершенно правы. В туториале лучше убрать упоминание 32-битной архитектуры.
Однако, хочу отметить, что сборка приложения под такую архитектуру делает возможным запуск продукта на большем количестве ПК.
В моем примере предполагается, что среда разворачивается скриптом на локальном хосте для сборки релиза. А дальше, все дальнейшие изменения в среду вносятся руками, не скриптом. Т.е. в дальнейшей сборке приложения данный скрипт не участвует.
Можно было бы описать более интеллектуальный скрипт, который запускается при сборке, обновляет зависимости, удаляет все лишнее, но тогда пришлось бы менять название статьи.
А как это выглядело? Скрипт устанавливает необходимые библиотеки или просто запускает сборку? Просто у нас в компании так же используется сборка на выделенном сервере, но make-скрипты просто запускают саму сборку. Предполагается, что все зависимости уже были установлены заранее.
Необходимо сделать пояснение о назначении bash-скрипта в примере. Он разворачивает среду для сборки приложения, ставит нужные библиотеки и пр. Далее, в процессе разработки, программист устанавливает необходимые компоненты в уже развернутой среде и добавляет команды в указанный bash-скрипт. Забытая зависимость всплывет при повторном разворачивании всей среды.
docker-файл содержит аналогичные команды скрипту bash, но в отличии от него используется намного чаще, как минимум для сборки каждого релиза. Соответственно, пропущенная зависимость будет выявлена гораздо быстрее в этом случае.