Qbs 2.0 တပ်ဆင်ရေးကိရိယာအစုံကို ထုတ်ပြန်ကြေညာလိုက်ပါပြီ။ Qbs ကိုတည်ဆောက်ရန်၊ Qt သည် မည်သည့်ပရောဂျက်များ၏ စုဝေးမှုကို စုစည်းရန် Qbs ကိုယ်တိုင်က ဒီဇိုင်းထုတ်ထားသော်လည်း မှီခိုမှုကြားတွင် Qt လိုအပ်ပါသည်။ Qbs သည် ပြင်ပ module များကိုချိတ်ဆက်နိုင်၊ JavaScript လုပ်ဆောင်ချက်များကိုအသုံးပြုကာ စိတ်ကြိုက်တည်ဆောက်မှုစည်းမျဉ်းများဖန်တီးနိုင်သည့် မျှမျှတတပြောင်းလွယ်ပြင်လွယ်ရှိသော တည်ဆောက်မှုစည်းမျဉ်းများကို သတ်မှတ်နိုင်စေမည့် ပရောဂျက်တည်ဆောက်မှုစခရစ်များကို သတ်မှတ်ရန်အတွက် QML ဘာသာစကား၏ ရိုးရှင်းသောဗားရှင်းကို အသုံးပြုပါသည်။
Qbs တွင်အသုံးပြုသော scripting language သည် ပေါင်းစပ်ဖွံ့ဖြိုးမှုပတ်ဝန်းကျင်များဖြင့် တည်ဆောက်ထားသော scripts များကို အလိုအလျောက်လုပ်ဆောင်ရန်နှင့် ခွဲခြမ်းစိတ်ဖြာရန်အတွက် လိုက်လျောညီထွေဖြစ်အောင်ပြုလုပ်ထားသည်။ ထို့အပြင်၊ Qbs သည် makefiles များကို မထုတ်ပေးသော်လည်း၊ make utility ကဲ့သို့သော ကြားခံများမပါဘဲ ကိုယ်တိုင်က compilers နှင့် linkers များ၏ launch များကို ထိန်းချုပ်ကာ မှီခိုမှုအားလုံး၏အသေးစိတ်ဂရပ်အပေါ်အခြေခံ၍ build process ကို ပိုကောင်းအောင်လုပ်ဆောင်သည်။ ပရောဂျက်ရှိ ဖွဲ့စည်းတည်ဆောက်ပုံနှင့် မှီခိုမှုများအကြောင်း ကနဦးဒေတာများ ရှိနေခြင်းသည် စာတွဲများစွာတွင် လုပ်ငန်းဆောင်ရွက်မှုများကို ထိထိရောက်ရောက် ပြိုင်တူလုပ်ဆောင်နိုင်စေပါသည်။ ဖိုင်အများအပြားနှင့် လမ်းကြောင်းခွဲများ ပါဝင်သော ပရောဂျက်ကြီးများအတွက်၊ Qbs ကို အသုံးပြု၍ ပြန်လည်တည်ဆောက်ခြင်း၏ စွမ်းဆောင်ရည်သည် ပြုလုပ်ခြင်းထက် အဆများစွာ ပိုမြန်နိုင်သည် - ပြန်လည်တည်ဆောက်ခြင်းသည် ချက်ချင်းနီးပါး လုပ်ဆောင်ပြီး ဆော့ဖ်ဝဲကို စောင့်ဆိုင်းရန် အချိန်မဖြုန်းသင့်ပါ။
2018 တွင် Qt ကုမ္ပဏီသည် Qbs ဖွံ့ဖြိုးတိုးတက်မှုကို ရပ်တန့်ရန် ဆုံးဖြတ်ခဲ့သည်ကို သတိရကြပါစို့။ Qbs ကို qmake အတွက် အစားထိုးအဖြစ် တီထွင်ထားသော်လည်း နောက်ဆုံးတွင် Qt အတွက် ပင်မတည်ဆောက်မှုစနစ်အဖြစ် CMake ကို ရေရှည်တွင် အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။ Qbs ၏ ဖွံ့ဖြိုးတိုးတက်မှုသည် ယခုအခါတွင် ရပ်ရွာနှင့် စိတ်ဝင်စားသော developer များမှ ပံ့ပိုးပေးသော လွတ်လပ်သော ပရောဂျက်တစ်ခုအဖြစ် ဆက်လက်လုပ်ဆောင်နေပါသည်။ Qt ကုမ္ပဏီ၏ အခြေခံအဆောက်အဦများကို ဖွံ့ဖြိုးတိုးတက်မှုအတွက် ဆက်လက်အသုံးပြုနေပါသည်။
ဗားရှင်းနံပါတ်တွင် သိသာထင်ရှားသောပြောင်းလဲမှုသည် QtScript တွင် အသုံးမပြုတော့ကြောင်း ကြေညာထားသည့် QtScript ကိုအစားထိုးသည့် JavaScript နောက်ခံဖိုင်အသစ်ကို အကောင်အထည်ဖော်ခြင်းနှင့် ဆက်စပ်နေသည်။ JavaScriptCore နှင့် ရှုပ်ထွေးသောချိတ်ဆက်မှုများကြောင့် ကျွန်ုပ်တို့ကိုယ်တိုင် QtScript ကို ဆက်လက်ထိန်းသိမ်းထားခြင်းသည် လက်တွေ့မကျဟု ယူဆပါသည်၊ လုံလုံလောက်လောက်နှင့် ကျစ်လစ်သိပ်သည်းသော backend အသစ်အတွက် အခြေခံအဖြစ် ရွေးချယ်ခံခဲ့ရသည် QuickJS JavaScript အင်ဂျင်ကို QEMU နှင့် FFmpeg ပရောဂျက်များကို တည်ထောင်ခဲ့သော Fabrice Bellard မှ ဖန်တီးခဲ့ခြင်းဖြစ်သည်။ အင်ဂျင်သည် ES6 သတ်မှတ်ချက်ကို ပံ့ပိုးထားပြီး လက်ရှိ analogues များထက် စွမ်းဆောင်ရည်တွင် သိသိသာသာ သာလွန်ကောင်းမွန်သည် (XS မှ 2019%, DukTape နှစ်ကြိမ်၊ JerryScript သုံးဆ၊ နှင့် MuJS ခုနစ်ဆ)။
assembly script များကို တီထွင်ခြင်း၏ ရှုထောင့်မှကြည့်လျှင် အင်ဂျင်အသစ်သို့ ကူးပြောင်းခြင်းသည် သိသာထင်ရှားသော အပြောင်းအလဲများကို မဖြစ်ပေါ်စေသင့်ပါ။ ကုန်ထုတ်စွမ်းအားသည်လည်း ခန့်မှန်းခြေအားဖြင့် တူညီသောအဆင့်တွင် ရှိနေမည်ဖြစ်သည်။ ကွဲပြားမှုများကြားတွင်၊ QtScript ကိုအသုံးပြုသောအခါ သတိမပြုမိသော လက်ရှိပရောဂျက်များတွင် ပြဿနာများကို ဖော်ထုတ်ပေးနိုင်သည့် nulls အသုံးပြုမှုအတွက် အင်ဂျင်အသစ်တွင် တင်းကျပ်သောလိုအပ်ချက်များရှိပါသည်။
source: opennet.ru