جستجو در تالارهای گفتگو

بارها شده است که شما به این فکر کنید برنامه‌ای بنویسید که تحت کامپایلر‌ها و سیستم‌عامل‌های مختلف اجرا شود. بنابراین شما باید از ویژگی‌های خاص این روش مراقب باشید چرا که هر سیستم‌عامل نسبت به خود ساختار و عملکرد متفاوتی را دارد. برای مثال بین رابط‌های برنامه‌نویسی Windows و لینوکس تفاوت بسیار است. یا نوع سیستم‌عامل‌های FreeBSD یا Linux تفاوت‌های بسیاری دارند که نباید کد‌های شما در همهٔ آن‌ها یکسان باشد. در این بخش من قصد دارم در رابطه با برخی از پرکاربرد‌ترین متغیر‌های CMake اشاره‌ای داشته باشم. بنابراین متغیر‌های زیر را در نظر بگیرید: متغیر UNIX: تمامی سیستم‌عامل‌های شبه‌-یونیکس مانند macOS را شامل می‌شود. درواقع زمانی true است که پلتفرم آن مک یا شبه‌-یونیکس باشد. متغیر WIN32: زمانی true خواهد بود که پلتفرم مقصد و توسعه ویندوز باشد. متغیر MINGW: پلتفرم ویندوز را بر پایهٔ MinGW شامل می‌شود و زمانی true خواهد بود که پلتفرم ویندوز همراه با کامپایلر Mingw پیکربندی شده باشد. متغیر MSVC: زمانی برابر true خواهد بود که پلتفرم ویندوز همراه با کامپایلر MSVC پیکربندی شده باشد. برای مثال اگر بخواهیم کاری انجام دهیم که صرفاً در پلتفرم ویندوز اعمال شود، باید آن را در دامنهٔ چنین شرطی قرار دهیم: if(WIN32) # for Windows operating system in general endif() شما می‌توانید در بین این کد متغیری تعریف کنید، مسیر کتابخانه‌ای را شناسایی کنید و یا هر کاری که نیاز است مختص پلتفرم ویندوز اعمال شود را تنظیم نمایید. مثال برای شناسایی محصولات شرکت اپل، تحتِ سیستم‌عامل‌های macOS، iOS و حتی watchOS , tvOS if(APPLE) # for MacOS X or iOS, watchOS, tvOS (since 3.10.3) endif() مثال برای بررسی نوع سیستم‌عامل‌های یونیکس و لینوکس به غیر از محصولات اپل if(UNIX AND NOT APPLE) # for Linux, BSD, Solaris, Minix endif() یک شرط نسبتاً کامل‌تر به صورت زیر خواهد بود: if(APPLE) # for MacOS X or iOS, watchOS, tvOS (since 3.10.3) MESSAGE("Current platform is macOS!") elseif(Linux AND NOT APPLE) # for Linux and not Unix base such as macOS! MESSAGE("Current platform is Linux!") elseif(WIN32) # for Windows only! MESSAGE("Current platform is Windows!") elseif(UNIX AND NOT APPLE) # for Linux, Unix base Free-BSD, Solaris, Minix MESSAGE("Current platform is Unix!") elseif(ANDROID) # for Linux base, Android only! MESSAGE("Current platform is Android!") endif() مثال برای تشخیص بر اساس نوع کامپایلر، مختص پلتفرم ویندوز تحت Mingw، MSys و MSVC if(MSVC OR MSYS OR MINGW) # for detecting Windows compilers endif() روش‌های دیگری نیز برای مقایسه صریح دیگری وجود دارد، برای مثال عملگر STREQUAL می‌تواند گزینهٔ خوبی در تشخیص و اعمال شرط باشد. مثل مقایسه‌ای، در صورتی که نوع کامپایلر Clang باشد یا گزینه‌های دیگر: if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang") # using Clang elseif (CMAKE_CXX_COMPILER_ID STREQUAL "GNU") # using GCC elseif (CMAKE_CXX_COMPILER_ID STREQUAL "Intel") # using Intel C++ elseif (CMAKE_CXX_COMPILER_ID STREQUAL "MSVC") # using Visual Studio C++ endif() در این صورت می‌توان بر اساس تشخیص شناسهٔ کامپایلر عملیات مورد نظر را اعمال کرد. همچنین می‌توان از عملگر MATCHES در بررسی شرط استفاده کرد: if (CMAKE_CXX_COMPILER_ID MATCHES "MSVC") MESSAGE("MSVC") endif() این مقاله ادامه خواهد داشت...

ابزار Android NDK به عنوان مجموعه‌از ابزار‌هایی است که به شما امکان آن را می‌دهد تا بخشی از برنامه‌های خود را به صورت بومی تحت زبان C و ++C توسعه دهید. بنابراین NDK از چندین کتابخانه‌ی در زمان اجرای ++C پشتیبانی می‌کند؛ در این پست در رابطه با آخرین تغییرات مرتبط با NDK اطلاع رسانی می‌شود. public class MyActivity extends Activity { /** * Native method implemented in C/C++ */ public native void computeFoo(); } بر اساس آخرین تغییرات کتابخانه‌های استاندارد libstdc++ به libc++ به‌روز رسانی و تمامی ویژگی‌های استاندارد C++17 پشتیبانی می‌شود که از نسخه‌ی R18 به بعد در دسترس قرار گرفته است. برخی از تغییرات مهم که لازم است به آن‌ها توجه شود به صورت زیر می‌باشند: تغییرات اساسی از نسخه‌ی NDK R17 آغاز شده است که در آن یکی از مهمترین و تکان‌ دهنده‌‌ترین تغیرات حذف GCC است که قرار بر این بود در نسخه‌های جدید NDK R18 پشتیبانی از GCC به صورت کامل حذف و Clang جایگزین آن شود. در نسخه‌ی R18 پشتیبانی از gnustl, gabi++و stlport حذف شده است. پشتیبانی از ICS از اندروید‌های ۱۴ و ۱۵ به بعد حذف شده است. بر اساس قوانی جدید گوگل، بار‌گذاری اپلیکیشن از تاریخ آگوست ۲۰۱۹ به بعد در فروشگاه گوگل پلی (Play Store) نیازمند نسخه‌ی معماری ۶۴ بیتی می‌باشد. پشتیبانی از C++17 در نسخه‌ی R18 به بعد تایید نهایی و قابل استفاده شده است و همچنین در نسخه‌های R19 استفاده از تمامی استاندارد‌های منسوخ شده پیشنهاد نمی‌شود. کلمات کلیدی new و delete در استاندارد جدید ++C از نسخه‌ی R18 منسوخ و در نسخه‌ی R19 به طور کامل حذف خواهند شد. پشتیبانی از مدیریت‌های استثناء (RTTI) در NDK به صورت پیش‌فرض غیر فعال می‌شود. مانند استثنائات، RTTI در libc++ پشتیبانی می‌شود، اما به صورت پیشفرض در android-build غیرفعال شده است که برای فعال‌سازی آن‌ می‌توانید از cmake و دیگر ابزار‌ها استفاده کنید. هیچ محدودیتی در رابطه با هِدر‌های سی‌پلاس‌پلاس در اندروید وجود ندارد. برای فعال سازی RTTI در برنامه‌ی شما در ndk-build کد زیر را در application.mk اضافه کنید: APP_CPPFLAGS := -frtti همچنین برای فعال سازی آن برای یک ماژول خاص در ndk-build کد دستوری زیر را استفاده کنید: LOCAL_CPP_FEATURES := rtti روش دیگر به صورت زیر است: LOCAL_CPPFLAGS := -frtti نکته: تحت این سند ویژگی‌های سیستمی STL در آینده حذف خواهند شد. توجه: libc++ یک کتابخانه‌ی سیستمی نیست. در صورتی که از libc++_shared.so استفاده می‌کنید باید آن را در داخل فایل apk خود قرار دهید. در صورتی که از Gradle استفاده می‌کنید این کار به صورت خودکار انجام می‌شود.

سلام برای زبان های برنامه نویسی و فریمورک های مختلف Package Manager وجود داره (خیلی خیلی کاربردیه?)، برای کیوت یکی پیدا کردم که زیاد هم فعال نیست ( qpm.io) و واقعا هم جای خالیش احساس میشه. مثلا به جای دانلود فایل zip از این مطلب، با یه حرکت jupiter به پروژه اضافه میشد.? چند نمونه از Package Manager های دیگر: فریمورک دات نت: NuGet جاوا اسکریپت: npm وب: Bower اگه برا کیوت سراغ دارید ما رو هم بی خبر نذارید...

سلام خسته نباشید . من می خواستم در مورد روش کلی استفاده از cmake در کامپایل کردن پروژه سی پلاس پلاس بدونم . من تو اینترنت خیلی دنبالش گشتم روش های مختلفی دیدم که استفاده می شد . اما هنوز روش کلی رو متوجه نشدم که بشه توی همه پروژه ها با ساختار پروژه مختلف استفاده کرد . مثلا اگه بخوام یک کتابخونه ای مثل sqlite3.h به پروژه اضافه کنم چطوری باید این کتابخونه رو در CmakeLists.txt معرفی کنم .

سلام، همانطور که می‌دانید شرکت Qt از سه نوع سیستم ساخت مختلف برای برنامه های Qt پشتیبانی می‌کند. برای کاربران کیوت، در حال حاضر qmake به طور گسترده استفاده می‌شود. CMake در حال محبوب شدن بوده و واضح است که به خوبی مورد استقبال قرار گرفته است. جایگاه سوم Qbs، با پذیرش قابل توجهی کوچکتر و کم اهمیت تر است (هرچند شرکت کیوت قبلاً اعلام کرده بود که این ابزار در نسخه‌ی ۶ کیوت به عنوان ابزار پیش‌فرض) ارائه خواهد شد. در یک نتیجه از آمار پرسش و سوال در مورد ابزار Qbs مشتریان این کمپانی به این نتیجه رسیده‌اند که مشتریان در آینده CMake و qmake را بر qbs ترجیح خواهند داد. بنابراین برای توسعه‌ی هرچه بیشتر دو ابزار قبلی از جمله CMake این شرکت تصمیم گرفته است تا منابع مرتبط با ابزار Qbs را از بین برده تا بتوانید به این صورت فرصت بهتری را برای افزایش کیفیت پشتیبانی از CMake را فراهم سازد. ابزار Qbs تا پایان سال ۲۰۱۹ همراه با نسخه‌ی ۴.۹ کیوت کریتور پشتیبانی خواهد شد. طبق گفته‌ی این کمپانی ابزار کیوبس تحت مجوز‌های تجاری و منبع باز است، بنابراین هرگونه حمایت جهت توسعه‌ی زیرساخت‌های آن را مورد حمایت نیز قرار می‌دهند. به هر حال حذف ان ابزار این اجازه را برای تیم پشتیبانی خواهد داد ت به طور قابل توجهی پشتیبانی در مورد CMake بهبود یابد.

معرفی ابزار کیوبس (Qbs) با آوای (“Cubes”) همانند qmake و cmake یک ابزار بسیار ساده و قدرتمند برای ساخت پروژه در پلتفرم‌های مختلف می‌باشد. این ابزار قابلیت استفاده در هر نوع پروژه ای را دارد به‌گونه‌ای که مهم نیست زبان‌برنامه نویسی٬ ابزار‌ها و حتی کتابخانه‌های مورد استفاده چه چیزی باشند. کیوبس یک ابزار همه کاره است که یک نمودار ساخت از پروژه‌های سطح بالا مانند (qmake و cmake) فراهم می‌کند که علاوه بر آن وظیفه اجرای دستورات نمودار ساخته شده در سطح پایین را مانند (make) فراهم می‌کند. در این کتاب ما به پیش معرفی آن می‌پردازیم چرا که قرار است در نسخه ۶ کیوت جایگزین نوع .pro از qmake باشد. کیوبس برنامه‌ها را بر پایه‌ی اطلاعاتی می‌سازد که در قالب یک فایل QML فراهم می‌شوند. هر فایل پروژه مشخص می‌کند که پروژه می‌تواند شامل چندین محصول باشد و شما نوع پروژه می‌توانیدمشخص کنید که یکی از انواع : نرم افزار، کتابخانه و غیره باشد. مشخصات سیستم مورد نیاز جهت استفاده از ابزار QBS حداقل نسخه ۵.۶.۰ به بعد خواهد بود. این ابزار همراه با Qt ارائه می‌شود. معرفی ساختار QBS در قالب QML کیوبس برای فایل پروژه خود از پسوند (*.qbs) استفاده می‌کند تا بتواند محتوای موجود در یک پروژه را معرفی کند. به طور کلی یک پروژه شامل چندین محتوا از محصول (پروژه) می‌باشد که در ادامه به آن‌ها اشاره شده است. یک محصول هدفی از روند ساخت است٬ به طور معمول یک برنامه کاربردی٬ کتابخانه و یا شاید یک چیز دیگر می‌تواند هدف آن باشد. جهت بررسی و مدیریت Qbs وارد بخش Setting یا Perefrences شوید و زبانه Qbs را انتخاب کنید تا در این بخش به نسخه و پیکربندی مقادیر مربوط به Qbs دسترسی داشته باشید. مباحثی که در این پست آموزشی پوشش داده خواهد شد: نحوه‌ی استفاده معرفی انواع پروژه‌ها معرفی برخی از پر کاربرد‌ترین آیتم‌های موجود در کیوبس مانند: پروژه Project زیر پروژه SubProject ویژگی‌ها (خواص‌ها) Properties اپلیکیشن Application اپلیکیشن سی‌پلاس‌پلاس CppApplication کتابخانه (پویا) DynamicLibrary کتابخانه (ایستا) StaticLibrary محصول Product پروفایل Profile گروه‌‌بندی Group وابستگی‌ها Depends و ... معرفی ماژول‌های پر کاربرد در کیوبس مانند: ماژول cpp جهت پیکربندی و پشتیبانی از C++ و ویژگی‌های آن در کیوبس پیکربندی ماژول‌های کیوت پیکربندی ویژگی‌های پردازنده پیکربندی اختصاصی اندروید پیکربندی اختصاصی محصولات اپل پیکربندی Xcode پیکربندی ماژول‌های کیوت پیکربندی Java و ... در صورت نیاز به مباحث دیگری نیز اشاره خواهد شد. نحوه‌ی استفاده جهت استفاده از کیوبس کافی است با سینتکس JavaScript یا QML آشنا باشید. جهت پیکربندی یک پروژه سی‌پلاس‌پلاس نمونه کُد آن به صورت زیر خواهد بود: import qbs 1.0 Application { name: "helloworld" files: "main.cpp" Depends { name: "cpp" } } انواع پروژه‌ها در کیوبس به چهار دسته‌ی زیر تقسیم بندی می‌شوند: تولید اپلیکیشن ساده (Application) این نوع پروژه به عنوان یک آیتم از محصول می‌باشد. Application { Depends { name: "cpp" } } تولید اپلیکیشن تحت وابستکی و ویژگی‌های سی‌پلاس‌پلاس (CppApplication) به عنوان یک محصول که تحت وابستگی‌های ماژول Cpp می‌باشد استفاده می‌شود. CppApplication { cpp.cxxLanguageVersion: "c++11" files: [ "main.cpp", "qml.qrc", ] } تولید پروژه در قالب کتابخانه‌ی پویا (DynamicLibrary) این نوع زمانی مورد استفاده قرار می‌گیرد که قرار است پروژه را در قالب یک خروجی کتابخانه‌ی پویا تولید کنیم. Product { type: "dynamiclibrary" } تولید پروژه در قالب کتابخانه‌ی استاتیک (StaticLibrary) این نوع زمانی مورد استفاده قرار می‌گیرد که قرار است پروژه را در قالب یک خروجی کتابخانه‌ی ایستا تولید کنیم. مثال Product { type: "staticlibrary" } در یک پروژه برای مشخص کردن فایل‌های قابل استفاده، نام و وابستگی‌ها به سادگی می‌توانند مشخص شوند. برای مثال در صورتی که پروژه‌ی شما تحت فناوری کیوت و Qt Quick است کافی است مقدار Depends را مشخص کنید: Depends { name: "Qt.core" } Depends { name: "Qt.quick" } لیستی از آیتم‌های (پر کاربرد و پایه) در QBS آیتم پروژه (Project) به عنوان یک آیتم از پروژه مجموعه‌ای از محصولات و خواص‌های مربوط به آن‌ها را ارائه می‌دهد. آیتم زیر پروژه‌ (Sub Project) یک ایتم زیر پروژه برای اضافه کردن یک پروژه به عنوان زیر مجموعه پروژه می‌باشد که در یک فایل جداگانه تعریف شده است. SubProject { filePath: "Subproject/OtherProject.qbs" Properties { name: "A sub-project" } } آیتم خواص (Properties) شرایط دستوری و خاصیت‌های مورد نیاز را برای یک محصول ایجاد می‌کند. Product { Properties { condition: qbs.targetOS.contains("windows") ... ..... } } - خواص condition از نوع بولین جهت شرط سازی سایر موارد در یک محصول را فراهم می‌کند. - خواص overrideListProperties لیست خواص تنظیم شده را که در ماژول‌ها به دست می آید را بر می‌گرداند. آیتم اپلیکیشن Application به عنوان یک آیتم با نوع 'application' برای یک محصول تعریف می‌شود. آیتم اپلیکیشن سی‌پلاس‌پلاس CppApplication به عنوان یک محصول با وابستگی‌های لازم در سی‌پلاس‌پلاس می‌باشد. آیتم کتابخانه‌‌ی پویا (DynamicLibrary) به عنوان یک آیتم برای محصول از نوع کتابخانه در قالب داینامیک (پویا) می‌باشد. import qbs Project { minimumQbsVersion: "1.7.1" CppApplication { type: "dynamiclibrary" ... Group { // Properties for the produced executable fileTagsFilter: "application" qbs.install: true } } } آیتم کتابخانه‌‌ی ایستا (StaticLibrary) به عنوان یک آیتم برای محصول از نوع کتابخانه در قالب استاتیک (ایستا) می‌باشد. import qbs Project { minimumQbsVersion: "1.7.1" CppApplication { type: "staticlibrary" ... Group { // Properties for the produced executable fileTagsFilter: "application" qbs.install: true } } } آیتم محصول (Product) به عنوان یک محصول (Product) به طور معمول نتیجه یک فرآیند ساخت را ارائه می‌دهد. مجموعه ای از فایلهای ورودی و خروجی را مشخص می‌کند. برای مثال نمونه‌ی زیر محصول را به عنوان یک پروژه سی پلای پلاس تنظیم می‌کند. Product { name: "helloworld" type: "application" files: "main.cpp" Depends { name: "cpp" } } خواص عضو در محصول (Product) aggregate : bool buildDirectory : path builtByDefault : bool condition : bool consoleApplication : bool destinationDirectory : string excludeFiles : stringList files : stringList multiplexByQbsProperties : stringList multiplexedType : stringList name : string qbsSearchPaths : stringList sourceDirectory : path targetName : string type : stringList version : string عضو aggregate اگر مقدارش برابر با true باشد، محصولی را که تحت وابستگی چندگانه باد در قالب یک محصول جمع آوری شده تولید خواهد کرد. در صورتی که شما نمی‌خواهید چنین کاری کنید بهتر است آن را به صورت تعریف نشده در نظر بگیرید. عضو buildDirectory دایرکتوری (ریشه مسیر) برای ساخت محصول است. فایل‌های تولید شده بعد از کامپایل در این مسیر قرار خواهند گرفت که به صورت پیش فرض توسط Qbs مقدار دهی می‌شود و کاربر نمی‌تواند آن را تغییر دهد. عضو buildByDefault تعیین کننده ساخت محصول است. اگر مقدارش false باشد، عمل ساخت محصول تنها در زمان درخواست صریح صورت خواهد گرفت که دستور ساخت آن توسط پارامتر --products و یا استفاده از --all-products برای دستور ساخت استفاده خواهد شد. مقدار آن به صورت پیشفرض true می‌باشد. عضو condition تعیین می‌کند که محصول ساخته خواهد شد، اگر مقدارش false باشد، محصول ساخته نخواهد شد. مقدار این عضو به صورت پیشفرض true است. در ویندوز، تعیین می‌کند که برنامه تحت GUI تولید شود یا تحت کنسول. اگر مقدار آن برابر true باشد، یک اپلیکیشن تحت کنسول تولید خواهد شد. در غیر این صورت یک اپلیکیشن تحت رابط کاربری (GUI) تولید خواهد شد. در پلتفرم‌های اپل، به نوع برنامه به صورت پیشفرض بستگی دارد. اگر مقدارش true باشد، یک برنامه اجرایی طبیعی تولید خواهد شد در غیر این صورت، بسته‌ی نرم‌ا‌فزاری تولید می‌شود. عضو destinationDirectory مسیری است که در هدف مصنوعات قرار می‌گیرد. اگر یک مسیر نسبی داده شود آن را به عنوان دایرکتوری پایه برای project.buildDirectory تنظیم می‌کند. عضو exclude-files لیست فایلهای منبع یا سورس را شاملش نمی‌شود. برای موارد معروف و خاص مفید است. عضو files لیستی از فایل های منبع یا سورس را شامل می‌شود. عضو multiplexByQbsProperties مشخص می‌کند که کدام خواص ماژول qbs برای استفاده از محصولات چندگانه استفاده شود. عضو multiplexedType نوع محصول را برای نمونه محصولات چند گانه مشخص می‌کند. در صورتی که نیاز به این خواص ندارید می‌توانید آن را تعریف نکنید. عضو name نام محصول را اعمال میکند. مقدار آن باید بر اساس یک عبارت جاوا اسکریپتی باشد. CppApplication { name: "hello" + "world" // valid } CppApplication { name: "app_" + qbs.targetOS.join("_") // invalid } عضو qbsSearchPath با مقدار project.qbsSearchPaths ادغام خواهد شد که لیستی از مسیرها را برای وارد کردن ماژول‌ها جستجو می‌کند. عضو sourceDirectory دایرکتوری یا مسیر منبع را برای محصول مشخص می‌کند. این دایرکتوری برای فایل‌هایی که در محصول تعریف شده اند می‌باشد. عضو targetName نام پایه فایل است که با هدف مصنوعات برای محصول می‌باشد. مقدار نام فایلی که نامعتبر باشد توسط کاراکتر زیر خط جایگزین می‌شود. عضو type برچسب‌های فایل مربط به مصنوعات محصول را مشخص می‌کند. عضو version شماره نسخه محصول را مشخص می‌کند. برای کتابخانه‌های به اشتراک گذاری شده و همچنین فایل Info.plist تحت محصولات اپل مورد استفاده می‌گیرد. آیتم پروفایل (Profile) به عنوان پروفایل سفارشی می‌تواند برای تعریف اهداف و شرایط ساخت بر روی یک ماشین خاص تنظیم شود. Profile { name: "my-special-profile" qbs.toolchainType: "gcc" qbs.targetPlatform: "linux" qbs.architecture: "armv7a" cpp.toolchainInstallPath: "/opt/special-gcc/bin" cpp.toolchainPrefix: "arm-linux-gnueabi-" } qbs.profiles: ["my-special-profile"] آیتم گروه (Group) جهت تعریف گروه‌های مختلف در فایل‌هایی که شامل یک محصول می‌باشند مورد استفاده قرار می‌گیرد. این ویژگی در محیط توسعه برای مدیریت پروژه‌های بزرگ بسیار کارآمد و مفید است. Application { Group { name: "common files" files: ["myclass.h", "myclass_common_impl.cpp"] } Group { name: "Windows files" condition: qbs.targetOS.contains("windows") files: "myclass_win_impl.cpp" } Group { name: "Unix files" condition: qbs.targetOS.contains("unix") files: "unixhelper.cpp" Group { name: "Linux files" condition: qbs.targetOS.contains("linux") files: "myclass_linux_impl.cpp" } Group { name: "FreeBSD files" condition: qbs.targetOS.contains("freebsd") files: "myclass_freebsd_impl.cpp" } Group { name: "macOS files" condition: qbs.targetOS.contains("macos") files: "myclass_macos_impl.cpp" } Group { name: "PS4 Pro files" condition: qbs.targetOS.contains("linux") files: "myclass_macos_impl.cpp" } Group { name: "Xbox One X files" condition: qbs.targetOS.contains("windows") files: "myclass_macos_impl.cpp" } } Group { name: "Files to install" qbs.install: true qbs.installDir: "share" files: "runtime_resource.txt" } } آیتم وابستگی (Depends) یک آیتم وابستگی در یک محصول یا ماژول تعریف می‌شود. به عنوان مثال محصول زیر ماژول Qt Quick، Qt Core و Qt Gui را بارگیری می‌کند. Product { Depends { name: "Qt.core" } Depends { name: "Qt.quick" } Depends { name: "Qt.gui" } } و یا به روش زیر تحت کتابخانه‌ی Qt ماژول‌های مربوطه را بارگیری می‌کند. Product { Depends { name: "Qt"; submodules: ["core", "quick", "gui"] } } ترکیبی از ماژول‌های مختلف از پروژه‌های مختلف به صورت زیر خواهد بود: Product { Depends { name: "cpp" } Depends { name: "MyEngine"; submodules: ["module1", "module2", "module3"] } Depends { name: "Qt"; submodules: ["core", "quick", "gui"] } } معرفی ماژول‌های پر کاربرد در Qbs ماژول cpp جهت پیکربندی و پشتیبانی از C++ و ویژگی‌های آن در کیوبس برخی از ویژگی‌های موجود در این ماژول به صورت زیر آورده شده‌اند: allowUnresolvedSymbols : bool alwaysUseLipo : bool architecture : string archiverName : string archiverPath : string assemblerFlags : stringList assemblerName : string assemblerPath : string automaticReferenceCounting : bool cFlags : stringList cLanguageVersion : stringList combineCSources : bool combineCxxSources : bool combineObjcSources : bool combineObjcxxSources : bool commonCompilerFlags : stringList compilerDefinesByLanguage : var compilerFrameworkPaths : pathList compilerIncludePaths : pathList compilerLibraryPaths : pathList compilerName : string compilerPath : string compilerPathByLanguage : var compilerVersionMajor : int compilerVersionMinor : int compilerVersionPatch : int compilerWrapper : stringList cppFlags : stringList cxxFlags : stringList cxxLanguageVersion : stringList cxxStandardLibrary : string debugInformation : bool defines : stringList discardUnusedData : bool distributionFrameworkPaths : pathList distributionIncludePaths : pathList distributionLibraryPaths : pathList driverFlags : stringList driverLinkerFlags : stringList dsymutilFlags : stringList dsymutilPath : string dynamicLibraries : stringList enableCompilerDefinesByLanguage : stringList enableExceptions : bool enableReproducibleBuilds : bool enableRtti : bool endianness : string entryPoint : string exceptionHandlingModel : string exportedSymbolsCheckMode : string frameworkPaths : pathList frameworks : stringList generateManifestFile : bool includePaths : pathList libraryPaths : pathList linkerFlags : stringList linkerMode : string linkerName : string linkerPath : string linkerWrapper : stringList lipoPath : string minimumIosVersion : string minimumMacosVersion : string minimumTvosVersion : string minimumWatchosVersion : string minimumWindowsVersion : string nmName : string nmPath : string objcFlags : stringList objcopyName : string objcopyPath : string objcxxFlags : stringList optimization : string platformDefines : stringList positionIndependentCode : bool prefixHeaders : pathList requireAppContainer : bool requireAppExtensionSafeApi : bool rpathOrigin : string rpaths : stringList runtimeLibrary : string separateDebugInformation : bool soVersion : string sonamePrefix : string staticLibraries : stringList stripName : string stripPath : string systemFrameworkPaths : pathList systemIncludePaths : pathList systemRunPaths : stringList treatSystemHeadersAsDependencies : bool treatWarningsAsErrors : bool useCPrecompiledHeader : bool useCxxPrecompiledHeader : bool useLanguageVersionFallback : bool useObjcPrecompiledHeader : bool useObjcxxPrecompiledHeader : bool useRPathLink : bool useRPaths : bool variantSuffix : string visibility : string warningLevel : string weakFrameworks : stringList windowsApiAdditionalPartitions : stringList windowsApiCharacterSet : string windowsApiFamily : string با توجه به لیست بالا، به برخی از ویژگی‌های موجود در این لیست اشاره می‌کنیم. ویژگی cxxLanguageVersion و cLanguageVersion جهت تعیین کردن پشتیبانی از نسخه‌ی زبان‌های سی‌پلاس‌پلاس و سی مورد استفاده قرار می‌گیرد که مشخصه‌های آن به ترتیب برای سی‌پلاس‌پلاس c++98 | c++11 | c++14 | c++17 و برای سی c89 | c98 | c11 می‌باشند. cpp.cLanguageVersion: "c11" cpp.cxxLanguageVersion: "c++17"

در گذشته، سیستم های نهفته اغلب سیستم عامل های بسیار کوچک بدون فایل سیستم را اجرا می کردند و یا توسط bare metal (به عملیات حذف رابط برای صحبت با سخت افزار و کم کردن پروسه، bare metal گفته می شود) اجرا می شدند. با افزایش قدرت و کاهش هزینه ی سخت افزار، برای مثال سیستم مجتمع در تراشه (system on chip, SOCs)، بسیاری از سیستم های نهفته به سمت تبدیل شدن به یک سیستم عامل کامل که اکثرا تحت لینوکس هستند، پیش میروند. یکی از مزیت های اجرای لینوکس بر روی سیستم نهفته، در دسترس بودن تمامی ابزار های آشنای لینوکس در این محیط است. در حالی که ممکن است محصول نهایی همراه آن ها عرضه نشود، شما به عنوان یک توسعه دهنده می توانید به شِل (shell)، دستورات اساسی و یک پشته شبکه کامل دسترسی داشته باشید. اگر اپلیکیشن نسبتا کوچک باشد، حتی ممکن است که کد بر روی یک سیستم نهفته، مانند Raspberry Pi، کامپایل شود. در این بخش، من بر برخی از مواردی که به طور خاص برای سیستم های نهفته مفید هستند، تمرکز خواهم کرد. این موارد شامل برنامه هایی جهت اجرا بر روی سیتم های نهفته یا ابزار هایی جهت اجرا بر روی ماشین های توسعه ی جداگانه است که برای توسعه و یا ارتباط با سیستم های نهفته مفید هستند. ابزار BusyBox همانطور که اشاره شد، دسترسی به شِل و دستورات لینوکسی/یونیکسی (برای مثال ls، grep و ...) برای سیستم های نهفته عموما مفید است. BusyBox ابزار های رایج یونیکس را در یک سیستم اجرایی کوچک فراهم می آورد. این دستورالعمل ها عمدتا جایگزینی برای دستورات کامل یونیکسی هستند که هم رایج اند و هم برخی گزینه های کم کاربرد را حذف کرده اند. این حالت به طور قابل توجهی سبب کوچکتر شدن رد پای کلی (در حافظه و فضای سیستم فایل) می شود که به طور تقریبی شامل 300 دستور و قابل تنظیم است، بنابراین شما می توانید دستورات مورد نظر را در زمان کامپایل اضافه یا حذف کنید. ابزار Minicom اغلب اوقات نیاز به برقراری ارتباط با سیستم نهفته از طریق یک رابط سریال وجود دارد. این نیاز ممکن است قبل از اینکه سیستم در حال اتصال به شبکه و در حال اجرا باشد، یا برای دسترسی به بارگذاری بوت صورت گیرد. برای انجام این کار یک برنامه شبیه ساز ترمینال در سمت کامپیوتر میزبان استفاده می شود. به نظر می رسد که Minicom شبیه ساز ترمینال استاندارد defacto برای لینوکس است. با وجود اینکه غیر گرافیکی است و استفاده از آن سخت است، شامل مجموعه ای از ویژگی های غنی است که ارزش صرف زمان برای یادگیری نحوه ی استفاده از آن را دارد. در پلتفرم ویندوز، ابزار استاندارد HyperTerminal بود، اما با شروع با ویندوز 7 دیگر پشتیبانی نشد یا در ویندوز گنجانده نشده است. شما می توانید نسخه تجاری HyperTerminal را که پشتیبانی می شود خریداری کنید یا از یکی از چندین برنامه های دیگر شبیه ترمینال استفاده کنید. اگر شما یک کپی از ویندوز XP دارید، می توانید فایل های مناسب (hypertrm.dll و hypertrm.exe) را به یک سیستم جدیدتر (از جمله ویندوز 10) کپی کنید و عموما کار می کند حتی اگر پشتیبانی نمی شود. ابزار ssh/sftp به طور معمول سیستم نهفته از شبکه پشتیبانی می کنند و اغلب این روش، ترجیحی برای انتقال فایل ها به سیستم در طول توسعه است. شما می توانید سرور ssh بر روی دستگاه اجرا کنید و سپس از ssh برای دسترسی به سیستم از یک دستگاه توسعه استفاده کنید. برنامه sftp نیز می تواند مفید باشد، ارائه یک رابط مشابه به ftp (برنامه انتقال فایل)، اما با استفاده از پروتکل امن تر ssh. اکثر محیط های یکپارچه ی توسعه نرم‌افزار (IDE)، مانند Qt Creator، با استفاده از ssh یا sftp برای انتقال فایل ها و اجرای دستورات از راه دور، از طریق یک رابط کاربری گرافیکی که معمولا ساده تر از فراخوانی دستورات به طور مستقیم است، پشتیبانی می کند. سرور های ssh جایگزینی وجود دارند که می توانند سبک تر و کم حجم تر از سرورهای کامل مانند OpenSSH و مناسب تر برای اجرای سیستم جاسازی شده. یک انتخاب محبوب Dropbear است. ابزار Adb Android Debug Bridge (adb) یک ابزار خط فرمان برای برقراری ارتباط با یک دستگاه برای انجام اقدامات مختلف مانند نصب، اشکالزدایی و دسترسی به شِل است. این یک ابزار استاندارد برای توسعه در اندروید است و در اندروید SDK گنجانده شده است. Adb همچنین می تواند در سیستم های غیر اندرویدی استفاده شود. ابزار Yocto bitbake پروژه Yocto یک ابتکار منبع باز است که قالب ها، ابزار ها و روش های ایجاد یک سیستم مبتنی بر لینوکس را برای محصولات نهفته فراهم می کند. این شرکت در سال 2010 به عنوان همکاری میان بسیاری از تولید کنندگان سخت افزار، فروشندگان سیستم عامل های open source و شرکت های الکترونیک تاسیس شد. Qt Company آن را به عنوان پایه Qt تجاری خود برای سیستم های نهفته، boot2qt استفاده می کند. Buildroot Buildroot یکی دیگر از ابزارهای رایج برای سیستم های نهفته برای تولید یک toolchain کامپایل چند سکویی، سیستم فایل ریشه، تصویر هسته و بوت لودر است. این ابزار قدرتمندتر از Yocto است، اما می تواند ساده تر از آن استفاده شود. انتخاب بین Yocto و buildroot، معمولا در ارزش و كيفيت تكنيكي خلاصه نميشود، بلكه انچه توسط bsp vendor ساپورت ميشود اهميت دارد.