Wprowadzono wydanie narzędzi do budowy Qbs 2.0. Do budowy Qbs wymagany jest Qt, chociaż sam Qbs jest zaprojektowany do organizacji budowy dowolnych projektów. Qbs używa uproszczonej wersji języka QML do definiowania scenariuszy budowy projektu, co pozwala na określenie elastycznych reguł budowy, w których mogą być zaangażowane zewnętrzne moduły, mogą być używane funkcje w JavaScript i mogą być tworzone dowolne zasady budowy.
Język skryptowy używany w Qbs jest dostosowany do automatyzacji generowania i analizowania scenariuszy budowy w zintegrowanych środowiskach programistycznych. Ponadto, Qbs nie generuje plików make, a sam, bez pośredników, takich jak narzędzie make, kontroluje uruchamianie kompilatorów i linkerów, optymalizując proces budowy na podstawie szczegółowego grafu wszystkich zależności. Posiadanie początkowych danych o strukturze i zależnościach w projekcie pozwala na efektywne równoległe wykonanie operacji w kilku wątkach. Dla dużych projektów, składających się z dużej liczby plików i podkatalogów, wydajność ponownej kompilacji przy użyciu Qbs może znacznie przewyższać make — ponowna kompilacja odbywa się niemal natychmiastowo i nie zmusza programisty do marnowania czasu na oczekiwanie.
Przypomnijmy, że w 2018 roku decyzją firmy Qt Company zaprzestano rozwoju Qbs. Qbs rozwijał się jako zamiennik qmake, ale ostatecznie zdecydowano się na użycie CMake jako głównego systemu budowy dla Qt w dłuższej perspektywie. Rozwój Qbs trwa teraz w formie niezależnego projektu, wspieranego przez społeczność i zainteresowanych programistów. Do rozwoju nadal wykorzystywana jest infrastruktura Qt Company.
Znacząca zmiana numeru wersji jest związana z wdrożeniem nowego backendu JavaScript, który zastępuje QtScript, ogłoszony jako przestarzały w Qt 6. Kontynuowanie wsparcia QtScript na własną rękę ze względu na skomplikowane powiązania z JavaScriptCore uznano za nierealistyczne, dlatego jako baza dla nowego backendu wybrano samodzielny i kompaktowy silnik JavaScript QuickJS stworzony przez Fabrice'a Bellarda, który wcześniej założył projekty QEMU i FFmpeg. Silnik wspiera specyfikację ES2019 i pod względem wydajności znacznie przewyższa istniejące analogi (XS o 35%, DukTape ponad dwa razy, JerryScript trzy razy, a MuJS siedem razy).
Z perspektywy tworzenia scenariuszy budowy przejście na nowy silnik nie powinno prowadzić do zauważalnych zmian. Wydajność również pozostanie na mniej więcej tym samym poziomie. Wśród różnic zauważalne są bardziej rygorystyczne wymagania w nowym silniku dotyczące użycia wartości nieokreślonych, co może ujawniać problemy w istniejących projektach, które pozostały niezauważone przy użyciu QtScript.
Źródło: opennet.ru
