Qbs 2.0 asembleo ileldono

Qbs 2.0-konstrua ilo-eldono lanĉita. Por konstrui Qbs, Qt estas postulata kiel dependeco, kvankam Qbs mem estas dizajnita por organizi la kunigon de iuj projektoj. Qbs uzas simpligitan version de la QML-lingvo por difini projektajn konstruskriptojn, kio ebligas al vi difini sufiĉe flekseblajn konstruregulojn en kiuj eksteraj moduloj povas esti konektitaj, JavaScript funkcioj povas esti uzataj, kaj arbitraj konstrureguloj povas esti kreitaj.

La skriptlingvo uzita en Qbs estas adaptita por aŭtomatigi la generacion kaj analizadon de konstruskriptoj de IDEoj. Krome, Qbs ne generas makefiles, kaj mem, sen perantoj kiel la make-utilo, kontrolas la lanĉon de kompililoj kaj ligiloj, optimumigante la konstruprocezon bazitan sur detala grafeo de ĉiuj dependecoj. La ĉeesto de komencaj datumoj pri la strukturo kaj dependecoj en la projekto permesas efike paraleligi la ekzekuton de operacioj en pluraj fadenoj. Por grandaj projektoj konsistantaj el granda nombro da dosieroj kaj subdosierujoj, la agado de rekonstruoj uzante Qbs povas plurfoje superi make - la rekonstruo estas preskaŭ tuja kaj ne igas la programiston pasigi tempon atendante.

Memoru, ke en 2018, la Kompanio Qt decidis ĉesi disvolvi Qbs. Qbs estis evoluigita kiel anstataŭaĵo por qmake, sed finfine estis decidite uzi CMake kiel la ĉefan konstrusistemon por Qt en la longa kuro. La evoluo de Qbs nun daŭris kiel sendependa projekto subtenata de komunumaj fortoj kaj interesitaj programistoj. La Qt Company-infrastrukturo daŭre estas uzita por evoluo.

Signifa ŝanĝo en la versinombro estas rilata al la efektivigo de nova JavaScript-backend, kiu anstataŭigis QtScript, kiu estis malrekomendita en Qt 6. Estis konsiderita nereale daŭrigi konservi QtScript memstare pro kompleksaj ligoj al JavaScriptCore, do mem. -sufiĉa kaj kompakta estis elektita kiel bazo por la nova backend QuickJS JavaScript-motoro kreita de Fabrice Bellard, kiu fondis la projektojn QEMU kaj FFmpeg. La motoro subtenas la specifon ES2019 kaj signife superas siajn ekzistantajn ekvivalentojn en rendimento (XS je 35%, DukTape je pli ol du fojojn, JerryScript je tri fojojn, kaj MuJS je sep fojojn).

El la vidpunkto de la disvolviĝo de konstruaj skriptoj, la transiro al nova motoro ne devus konduki al rimarkindaj ŝanĝoj. Regado ankaŭ restos proksimume la sama. El la diferencoj, ekzistas pli striktaj postuloj en la nova motoro por la uzo de nulaj valoroj, kiuj povas malkaŝi problemojn en ekzistantaj projektoj, kiuj pasis nerimarkitaj dum uzado de QtScript.

fonto: opennet.ru

Aldoni komenton