Подано випуск складального інструментарію 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.
Джерело: opennet.ru