The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск сборочного инструментария Qbs 2.0

25.04.2023 21:45

Представлен выпуск сборочного инструментария Qbs 2.0. Для сборки Qbs в числе зависимостей требуется Qt, хотя сам Qbs рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки.

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

Напомним, что в 2018 году компанией Qt Company было принято решение о прекращении разработки Qbs. Qbs развивался как замена qmake, но в конечном счёте было решено использовать CMake в качестве основной сборочной системы для Qt в долгосрочной перспективе. Разработка Qbs теперь продолжена в форме независимого проекта, поддерживаемого силами сообщества и заинтересованными разработчиками. Для разработки пока продолжает использоваться инфраструктура Qt Company.

Значительное изменение номера версии связано с реализацией нового JavaScript-бэкенда, который пришёл на смену QtScript, объявленному устаревшим в Qt 6. Продолжать сопровождение QtScript своими силами из-за сложных привязок к JavaScriptCore признано нереалистичным, поэтому в качестве основы для нового бэкенда выбран самодостаточный и компактный JavaScript-движок QuickJS, созданный Фабрисом Белларом (Fabrice Bellard), основавшим в своё время проекты QEMU и FFmpeg. Движок поддерживает спецификацию ES2019 и по производительности заметно превосходит имеющиеся аналоги (XS на 35%, DukTape более чем в два раза, JerryScript в три раза, а MuJS в семь раз).

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

  1. Главная ссылка к новости (https://www.qt.io/blog/qbs-2.0...)
  2. OpenNews: Выпуск сборочного инструментария Qbs 1.21 и начало тестирования Qt 6.3
  3. OpenNews: Проект Qt прекращает разработку сборочной системы Qbs в пользу CMake
  4. OpenNews: Выпуск сборочной системы Meson 1.0
  5. OpenNews: Сбои в системах сборки из-за изменения контрольных сумм архивов в GitHub
  6. OpenNews: Facebook опубликовал систему сборки Buck2
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59032-qbs
Ключевые слова: qbs, build
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (56) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, DEF (?), 22:22, 25/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Дожили. Для сборки билд-тулзы нужен Qt. Скоро ядро Linux без GTK+ не будет собираться.
     
     
     
     
    Часть нити удалена модератором

  • 4.20, EULA (?), 07:17, 26/04/2023 [ответить]  
  • –5 +/
    Для сборки Cmake нужен Qt. Иначе Cmake-GUI не соберется
     
  • 2.12, Вирт (?), 23:54, 25/04/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >      Скоро ядро Linux без GTK+ не будет собираться.

    Ну уже много лет с qt/gtk+ ядро конфигурируется намного легче.
    Так как "make menuconfig" не такой удобный как "make gconfig/qconfig"

     
     
  • 3.31, 1 (??), 10:33, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Попробуй в vi. Тебе понравится
     
     
  • 4.40, Аноним (40), 16:20, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я лучше в плейере. Там хоть музыка, а не просто писк.
     
  • 3.45, Аноним (45), 18:09, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > "make menuconfig" не такой удобный как "make gconfig/qconfig"

    А у меня всё с точностью до наоборот. Считаю самым удобным как раз menuconfig. Ну и oldconfig при минорных апдейтах.

     
  • 2.39, Аноним (40), 16:17, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    GTK надо писать именно так "GTK", без знака "+" https://www.opennet.ru/opennews/art.shtml?num=50115
     

  • 1.3, InuYasha (??), 22:29, 25/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    К (счастью|сожалению) многие уже пересели на cmake, так что, увы. А ещё говорят, что и его уже абстрагировали. Но идея была интересная.
     
     
  • 2.5, Аноним (5), 22:41, 25/04/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Уже дропнули и перешли на meson, на cmake всякая маргинальщина.
     
     
  • 3.35, Аноним (35), 12:53, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, meson тоже напоминает Autotls и солянку из Perl^W Python скриптов.
    Функционала больше, но вот сама реализация конечно печальная.
     
  • 3.51, InuYasha (??), 11:56, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Окей, так и запишем: телеграм - маргинальщина.


     
     
  • 4.63, Аноним (63), 13:42, 04/05/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Именно так.
     
  • 2.21, EULA (?), 07:19, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы собрать проект для STM32 нужно всего чуть больше 1900 строк кода в CMAKE. Или чуть более 600 в QBS.
     
     
  • 3.22, Советский инженер (?), 07:22, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А про какие строки разговор? Ты считаеш строки проекта? Или еще и то что поставляется штатно с билдсистемой?

    Если про юзерские, то как-то сильно много.
    А если про все , то всем пофиг что там под капотом.

     
     
  • 4.23, EULA (?), 07:36, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А про какие строки разговор? Ты считаеш строки проекта? Или еще и
    > то что поставляется штатно с билдсистемой?
    > Если про юзерские, то как-то сильно много.
    > А если про все , то всем пофиг что там под капотом.

    Про юзерские. Так как надо указать ручками смещение, опции кросскомпилятора, либы STM32 (HAL) для подключения устройств контроллера и подключенного оборудования и прочие параметры сборки.

    Например, чтобы реализовать в проекте компиляцию либ работы microsd с FAT32 на контроллере STM32F103 нужно дописать около кполучтысячи строк кода  в проект CMAKE.
    Проект CMAKE осцилогрофа на STM32 Discovery более 600 килобайт весит, при том, что сама прошивка 256 КБ. Если это все не прописать, то в каждую либу нужно вносить ручками частоту работы процессора, частоту работы шины и т.д.

    Да, на форумах есть готовые CMAKE файлы для камушков и либ к ним. Но это не штатный код CMAKE.

     
     
  • 5.24, Бывалый смузихлёб (?), 07:50, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Звучит как какой-то безумный онанизм вместо использования штук вроде стм32кубИде хотя бы в плане начальной генерации кода

    А если стм-ина жирная, то даже с тактированиями писаниной можно просто задолбаться

     
     
  • 6.27, EULA (?), 08:51, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    STM32Cube помогает настроить ножки самого камня, а не настроить то, что эти ножки будут пинать.
    FAT32 можно поддерживать на SD-карте, USB-диске, flash-памяти. Либа одна, а настройки у нее разные, которые не задашь через кубик.

    > то даже с тактированиями писаниной можно просто задолбаться

    Вот поэтому и надо писать ооооооооооооочень много кода CMAKE.

     
     
  • 7.52, InuYasha (??), 11:58, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я не знаком со спецификой, но написать простой Makefile - ещё хуже будет?
     
     
  • 8.55, EULA (?), 13:20, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вроде не хуже Но и не лучше QBS-ом проще ... текст свёрнут, показать
     
  • 8.56, kuzulis (?), 14:18, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тут основной профит от Qbs в том, что он передает в IDE всю инфу о собираемом пр... текст свёрнут, показать
     
     
  • 9.59, InuYasha (??), 14:42, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Т е тут вмешивается извечная проблема борьбы ИДЕ с проектом и CLI Я просто не ... текст свёрнут, показать
     
     
  • 10.61, kuzulis (?), 14:53, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    ИМХО, сама ИДЕ не должна ничего знать о том как и что и каким компилятором собир... текст свёрнут, показать
     
     
  • 11.62, InuYasha (??), 14:57, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, тогда тебе и Kate - IDE А мне нужен годный дебуггер, дизасёмблер, графопост... текст свёрнут, показать
     
  • 6.60, kuzulis (?), 14:44, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не не. Тут речь идет, как я понял, не о генерации с помощью кубика.

    Вот сгенерили мы целиком сам ХАЛ и некоторую обвязку кубиком.

    Теперь надо как то эти файлы подключить к проекту.

    Путей два:

    1. Или прописывать их и их зависимости ручками.

    2. Или взять какое то готовое решение.

    Вот для STM32 на гитхабе есть готовое решение на CMake. Где достаточно указать путь к директории с ХАЛ-ом, а уже отдельные компоненты: тип MCU, модули GPIO, таймеры, USB и прочее подключать через готовые штукенции, реализованные в решении, где пользователь даже не знает, какие файлы из ХАЛ подтянулись.

    Поменяли тип MCU и автоматом потянулись из ХАЛ все нужное для этого MCU, красота.

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

    В этом случае на Qbs это будет выглядеть гооораздо прозрачнее, проще, красивее и т.п. чем на CMake.

     

  • 1.6, Ванёк (?), 22:41, 25/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    make при грамотном использовании не оказывает ощутимого влияния на общее время сборки/пересборки проекта
     
     
  • 2.8, Аноним (8), 22:47, 25/04/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    в принципе, для хелловорлдов подойдет и однострочная команда gcc, размещенная в виде коммента в laba1.c. Что касается крупных проектов, то make им не подойдет.
     
     
  • 3.26, Совершенно другой аноним (?), 08:45, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ядро Linux достаточно крупный проект?
     
     
  • 4.29, Советский инженер (?), 10:05, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что то тут https://www.kernel.org/doc/html/v4.10/process/changes.html список необходимого сильно шире чем make и компилятор. Даже перл присутствует.
    Так что маке сам по себе это как раз то для хеловордов. Без настоящего ЯП типа перла - унылая поделка.
     
     
  • 5.32, Совершенно другой аноним (?), 10:45, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я знаю - perl там используется в основном для вспомогательных вещей, типа проверки патчей, работы со списками сопровождающих и тому подобных вещей, не влияющих на сам процесс сборки.
     
  • 2.11, Аноним (11), 23:47, 25/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Оказывает, к сожалению. Время пересборки (incremental build) вместе с make в сотни раз медленнее чем с qbs, meson, ninja, да почти что угодно (кроме всратого scons который умудряется делать инкрементные сборки медленнее чем make сделанный 40 лет назад).

    К слову Qbs не замена make, а скорее замена meson+ninja, cmake+make, SCons, MSBuild autotools+make и вот такого прочего. т.е. не просто сборка, а полный комбайн.


    Я не агитирую переходить на Qbs, к сожалению он сильно отстает по фичам от cmake а по интеграции с IDE от вообще чего угодно (кроме qt creator на все остальное забей).

     
     
  • 3.14, Аноним (14), 00:20, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "В сотни раз" -- сильное преувеличение. https://hamelot.io/programming/make-vs-ninja-performance-comparison/ И скорость сборки зависит не от инструментария автоматизации сборки, а от компилятора -- он требует больше всего ресурсов (любых, не важно, ЦП, памяти или I/O), поэтому производительность упирается именно в него.
     
     
  • 4.33, Ванёк (?), 10:55, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, именно так, всё упирается в компилятор, а не в make или что-то ещё.
     
  • 4.36, Аноним (36), 15:16, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Для полной пересборки да, все упирается в производительность компилятора.

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

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

     
     
  • 5.53, InuYasha (??), 12:01, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    По-моему, сравнивать даты изменения *.c и *.obj умел ещё make - разве нет?
     
     
  • 6.54, InuYasha (??), 12:03, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почитал остальной ваш тред - можете не отвечать :D
     
  • 4.38, Аноним (38), 15:50, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> Время пересборки (incremental build)
    > скорость сборки зависит не от инструментария автоматизации сборки, а от компилятора

    По вашей ссылке речь идёт о чистой сборке, а начальное сообщение — про инкрементальную сборку, которая нужна разработчикам десятки и сотни раз в день.

    Для make совершенно типично долго обходить все каталоги, чтобы через 10+ секунд скомпилировать и перелинковать один файл. Для больших проектов это просто ад.

     
     
  • 5.43, Ванёк (?), 17:19, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Пересборку make делает очень быстро. У меня каждый раз делается замер общего времени компиляции/сборки, времени компиляции каждого модуля, времени линковки и прочего. Причём сценарии сборки make довольно большие (более 1500 строк чистого кода - это уже после вычета комментариев и пустых строк) и используется Perl для вспомогательных целей. Вывод следующий: как для полной сборки проекта, так и для частичной пересборки, ситуация примерно одна и та же, а именно: практически всё время затрачивается на работу компилятора gcc/clang, а всё остальное (make, линковщик...) занимает очень незначительное время, уменьшение которого на общее время как-то существенно повлиять не может.
     
  • 3.34, Ванёк (?), 11:11, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Время сборки при использовании make практически такое же, как при использовании любого другого инструментария для организации сборки. Всегда замеряю общее время сборки проекта, каждого модуля в отдельности, и всегда оказывается, что практически всё время сборки тратится на работу компилятора gcc/clang (clang обычно чуть быстрее gcc), а не make. Это, конечно, при условии грамотного написания сценариев make. Всё, что вы можете выиграть от перехода на более новые системы сборки - это десятые доли секунды.
     
     
  • 4.42, Аноним (38), 17:18, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Всё, что вы можете выиграть от перехода на более новые системы сборки - это десятые доли секунды.

    Всё, что могут выиграть пользователи — это проценты, да. А разработчки могут каждый день экономить по пол часа. Вообще — тут как с git.
    Ситуация похожа на то, что Linus говорил про git (https://www.youtube com/watch?v=4XpnKHJAok8&t=3287s).
    Разница не просто «быстрее или медленнее».
    Если сборка занимает секунду, то в случае сомнений можно нажать build и посмотреть результат.
    А с make нужно ждать 10-20-30 секунд, и это всё меняет.

     
     
  • 5.44, Ванёк (?), 17:25, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Замеры времени показывают, что практически всё время затрачивается на работу компилятора. Make, линковщик и прочее занимает максимум 5% времени в худшем случае. Если у кого-то иначе, смотрите, что не так с вашими сценариями сборки make, изучите make лучше - у него много опций и возможностей которые надо понимать, чтобы всё хорошо работало. Также надо понимать опции компиляторов gcc/clang, некоторые из которых непосредственно взаимосвязаны с работой make.
     
     
  • 6.46, Аноним (38), 19:59, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы понимаете, что значит incremental build Давайте напомню это повторная сборк... большой текст свёрнут, показать
     
     
  • 7.47, Ванёк (?), 21:40, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Никто каждый раз не перекомпилирует весь проект. Это обычный режим работы. Все в курсе об этом режиме. Для этого режима и предназначен make и работает он очень быстро. Если в проекте нет изменений, то на среднем проекте проверка всего и вся занимает десятые доли секунды. У меня он работает так. Всё работает быстро, и ничего не тормозит. При этом сценарии make не маленькие - более 1500 строк (это уже за вычетом комментариев и пустых строк).
     
  • 7.48, Ванёк (?), 22:03, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Выше уже приводили ссылку, где сравнивается производительность make и ninja, которая разрабатывалась как улучшенная и ускоренная альтернатива make: https://hamelot.io/programming/make-vs-ninja-performance-comparison/
    Это правдивые данные. По факту разница в производительности между ними очень незначительная, как для полной, так и для частичной пересборки проекта, хотя для частичной пересборки она таки есть, но абсолютно некритичная - десятые доли секунды. То есть для тех, у кого уже есть отработанные годами сценарии сборки make, переходить на что-то другое смысла никакого нет.
     
  • 3.57, kuzulis (?), 14:21, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > (кроме qt creator на все остальное забей).

    Есть же еще плагин для VSCode. ))

     

  • 1.10, Я (??), 23:24, 25/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    когда уже сборочная система на расте?
     
     
  • 2.13, Вирт (?), 23:56, 25/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > когда уже сборочная система на расте?

    давно уже есть: https://www.opennet.ru/opennews/art.shtml?num=58933

     

  • 1.15, Аноним (15), 03:44, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    основная проблема qbs была в отсутствии документации, qbs-файлы писались наугад по клочкам информации с форумов. проблема осталась
     
     
  • 2.30, Советский инженер (?), 10:07, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Основная проблема курса - что ее пилили и пилят на общественных началах. А все остальное - это производные.
     
     
  • 3.41, Аноним (40), 16:27, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А надо, чтобы пилил закрытый НИИ, тогда всё по ГОСТам.
     

  • 1.17, Аноним (15), 03:49, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > выбран самодостаточный и компактный JavaScript-движок QuickJS,
    > 2021-03-27:

        New release (Changelog)

    для поддержки легаси заменили легаси на легаси

     
  • 1.18, Аноним (18), 04:37, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, почему не выбрали QJSEngine из состава Qt, который и является заменой устаревшему QtScript.
     
     
  • 2.19, Аноним (19), 07:11, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы не тянуть qdeclarative в зависимости, наверно
     
  • 2.37, ABBAPOH (ok), 15:49, 26/04/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В оригинальной новости про это написано - он не позволяет перехватывать доступ к пропертям (точнее позволяет но очень криво и медленно - QtCreator резолвился в 2 раза медленее с QJSEngine бэкендом)
     
  • 2.58, kuzulis (?), 14:29, 27/04/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А еще может быть захотят дропнуть саму Qt.

    Оставят может только сами GUI конфигурялки на Qt.

    И тогда аргумент жирных троллей о том что для сборки Qbs нужен Qt отводится сам собой. ))

     

  • 1.25, nc (ok), 08:21, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    qbs хотя-бы выглядит понятно. Я правда не понимаю зачем там императивный код - считаю что в файлах проектов достаточно перечня файлов исходников и параметров компиляции, заданных в удобном структурированном формате. В удобном как для человека, так и для IDE. Ну да ладно. По сравнению с make и cmake это все равно прогресс.
     
  • 1.28, Аноним (28), 09:09, 26/04/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Только premake, только хардкор
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру