परिचय

यह लेख भारी संख्या में C / C ++ प्रोजेक्ट्स में प्रयुक्त CMake बिल्ड सिस्टम के उपयोग पर चर्चा करता है। यह दृढ़ता से अनुशंसा की जाती है कि आप सीएमके भाषा के सिंटैक्स को गलत समझने से बचने के लिए मैनुअल का पहला भाग पढ़ें, जो पूरे लेख में स्पष्ट रूप से दिखाई देता है।

सीएमके लॉन्च

निम्नलिखित सीमेक भाषा का उपयोग करने के उदाहरण हैं जिनका आपको अभ्यास करना चाहिए। मौजूदा आदेशों को संशोधित करके और नए जोड़कर स्रोत कोड के साथ प्रयोग करें। इन उदाहरणों को चलाने के लिए, आधिकारिक वेबसाइट से CMake इंस्टॉल करें ।

कार्य सिद्धांत

CMake बिल्ड सिस्टम अन्य प्लेटफ़ॉर्म-निर्भर उपयोगिताओं (उदाहरण के लिए, निंजा या मेक ) पर एक आवरण है। इस प्रकार, विधानसभा की प्रक्रिया में ही, यह कितना भी विरोधाभासी लग सकता है, यह सीधे भाग नहीं लेता है।

CMake बिल्ड सिस्टम औपचारिक CMake भाषा में बिल्ड नियमों के विवरण के साथ CMakeLists.txt फाइल को स्वीकार करता है, और फिर आपके प्लेटफॉर्म पर स्वीकृत उसी निर्देशिका में मध्यवर्ती और देशी बिल्ड फाइलें बनाता है।

उत्पन्न फ़ाइलों में सिस्टम उपयोगिताओं, निर्देशिकाओं और संकलक के विशिष्ट नाम होंगे, जबकि सीएमके कमांड केवल संकलक की अमूर्त अवधारणा का उपयोग करते हैं और प्लेटफ़ॉर्म-निर्भर उपकरणों से बंधे नहीं होते हैं जो विभिन्न ऑपरेटिंग सिस्टम पर बहुत भिन्न होते हैं।

सीएमके संस्करण की जाँच

cmake_minimum_required कमांड CMake के रनिंग संस्करण की जांच करता है: यदि यह निर्दिष्ट न्यूनतम से कम है, तो CMake एक घातक त्रुटि के साथ समाप्त होता है। एक उदाहरण जो किसी भी CMake फ़ाइल की शुरुआत में इस कमांड के विशिष्ट उपयोग को प्रदर्शित करता है:

 #     CMake: cmake_minimum_required(VERSION 3.0) 

जैसा कि टिप्पणियों में कहा गया है, cmake_minimum_required कमांड सभी संगतता झंडे सेट करता है (देखें cmake_policy )। कुछ डेवलपर्स जानबूझकर सीएमके का एक कम संस्करण सेट करते हैं, और फिर कार्यक्षमता को मैन्युअल रूप से समायोजित करते हैं। यह आपको सीएमके के प्राचीन संस्करणों का एक साथ समर्थन करने की अनुमति देता है और कुछ स्थानों पर नई सुविधाओं का लाभ उठाता है।

प्रोजेक्ट डिजाइन

किसी भी CMakeLists.txt की शुरुआत में CMakeLists.txt एकीकृत वातावरण और अन्य विकास साधनों के साथ बेहतर डिजाइन के लिए प्रोजेक्ट टीम के साथ प्रोजेक्ट विशेषताओं को निर्दिष्ट करना चाहिए।

 #    "MyProject": project(MyProject VERSION 1.2.3.4 LANGUAGES C CXX) 

यह ध्यान देने योग्य है कि यदि LANGUAGES कीवर्ड छोड़ा जाता है, तो डिफ़ॉल्ट भाषा C CXX । आप कीवर्ड NONE को भाषाओं की सूची के रूप में लिखकर किसी भी भाषा के संकेत को अक्षम कर सकते हैं या केवल एक खाली सूची छोड़ सकते हैं।

स्क्रिप्ट फ़ाइलों को चलाना

include कमांड अपने कॉल की लाइन को निर्दिष्ट फ़ाइल के कोड के साथ बदल देती है, C / C ++ प्रीप्रोसेस के समान कार्य करती है। यह उदाहरण वर्णित कमांड के MyCMakeScript.cmake स्क्रिप्ट फ़ाइल MyCMakeScript.cmake चलाता है:

 message("'TEST_VARIABLE' is equal to [${TEST_VARIABLE}]") #   `MyCMakeScript.cmake`  : include(MyCMakeScript.cmake) message("'TEST_VARIABLE' is equal to [${TEST_VARIABLE}]") 

इस उदाहरण में, पहला संदेश सूचित करेगा कि TEST_VARIABLE चर TEST_VARIABLE अभी तक परिभाषित नहीं किया गया है, हालांकि, यदि MyCMakeScript.cmake स्क्रिप्ट इस चर MyCMakeScript.cmake है, तो दूसरा संदेश पहले से ही परीक्षण चर के नए मूल्य के बारे में सूचित करेगा। इस प्रकार, include कमांड द्वारा शामिल स्क्रिप्ट फ़ाइल अपना स्वयं का दायरा नहीं बनाती है, जिसका उल्लेख पिछले लेख में टिप्पणियों में किया गया था ।

निष्पादन योग्य फ़ाइलों का संकलन

add_executable कमांड स्रोत सूची से दिए गए नाम के साथ निष्पादन योग्य फ़ाइल को संकलित करता है। यह ध्यान रखना महत्वपूर्ण है कि अंतिम फ़ाइल नाम लक्ष्य प्लेटफ़ॉर्म पर निर्भर करता है (उदाहरण के लिए, <ExecutableName>.exe या बस <ExecutableName> )। इस आदेश को कॉल करने का एक विशिष्ट उदाहरण:

 #    "MyExecutable"  #  "ObjectHandler.c", "TimeManager.c"  "MessageGenerator.c": add_executable(MyExecutable ObjectHandler.c TimeManager.c MessageGenerator.c) 

पुस्तकालय संकलन

add_library आदेश स्रोत से निर्दिष्ट दृश्य और नाम के साथ लाइब्रेरी को संकलित करता है। यह ध्यान रखना महत्वपूर्ण है कि अंतिम पुस्तकालय का नाम लक्ष्य मंच पर निर्भर करता है (उदाहरण के लिए, lib<LibraryName>.a या <LibraryName>.lib )। इस आदेश को कॉल करने का एक विशिष्ट उदाहरण:

 #    "MyLibrary"  #  "ObjectHandler.c", "TimeManager.c"  "MessageConsumer.c": add_library(MyLibrary STATIC ObjectHandler.c TimeManager.c MessageConsumer.c) 

• स्टेटिक कीवर्ड को स्टेटिक कीवर्ड द्वारा दूसरे तर्क के रूप में परिभाषित किया जाता है और यह संकलन समय पर निष्पादन योग्य फ़ाइलों और अन्य पुस्तकालयों से जुड़ी ऑब्जेक्ट फ़ाइलों का संग्रह होता है;
• डायनामिक लाइब्रेरी को दूसरे तर्क के रूप में SHARED कीवर्ड द्वारा निर्दिष्ट किया गया है और प्रोग्राम निष्पादन के दौरान ऑपरेटिंग सिस्टम द्वारा लोड किए गए बाइनरी लाइब्रेरी हैं;
• मॉड्यूलर पुस्तकालयों को दूसरे तर्क के रूप में MODULE कीवर्ड द्वारा परिभाषित किया गया है और निष्पादन योग्य तकनीक द्वारा निष्पादन तकनीक का उपयोग करते हुए बाइनरी लाइब्रेरी भरी हुई हैं;
• ऑब्जेक्ट लाइब्रेरी को OBJECT कीवर्ड द्वारा दूसरे तर्क के रूप में परिभाषित किया गया है और यह संकलन समय पर निष्पादन योग्य फ़ाइलों और अन्य पुस्तकालयों से जुड़ी ऑब्जेक्ट फ़ाइलों का एक सेट है।

लक्ष्य के लिए स्रोत जोड़ना

ऐसे मामले हैं जिनमें लक्ष्य के लिए स्रोत फ़ाइलों के एकाधिक परिवर्धन की आवश्यकता होती है। ऐसा करने के लिए, target_sources कमांड target_sources की target_sources , जो कई बार स्रोतों को लक्ष्य में जोड़ सकती है।

target_sources कमांड में पहला तर्क add_library या add_executable का उपयोग करके पहले बताए गए लक्ष्य का नाम है, और बाद के तर्कों को जोड़े जाने वाली स्रोत फ़ाइलों की एक सूची है।

बार-बार कॉल करने के लिए target_sources उस स्रोत फ़ाइलों को लक्ष्य में जोड़ते हैं जिस क्रम में उन्हें बुलाया गया था, इसलिए नीचे के दो ब्लॉक कोड कार्यात्मक रूप से समतुल्य हैं:

 #    "MyExecutable"   # "ObjectPrinter.c"  "SystemEvaluator.c": add_executable(MyExecutable ObjectPrinter.c SystemEvaluator.c) #    "MyExecutable"  "MessageConsumer.c": target_sources(MyExecutable MessageConsumer.c) #    "MyExecutable"  "ResultHandler.c": target_sources(MyExecutable ResultHandler.c) 

 #    "MyExecutable"   # "ObjectPrinter.c", "SystemEvaluator.c", "MessageConsumer.c"  "ResultHandler.c": add_executable(MyExecutable ObjectPrinter.c SystemEvaluator.c MessageConsumer.c ResultHandler.c) 

जनरेट की गई फाइलें

add_executable और add_library द्वारा उत्पन्न आउटपुट फ़ाइलों का स्थान केवल पीढ़ी स्तर पर निर्धारित किया जाता है, हालांकि, इस नियम को कई चर के साथ बदला जा सकता है जो बाइनरी फ़ाइलों के अंतिम स्थान को निर्धारित करते हैं:

• चर RUNTIME_OUTPUT_DIRECTORY और RUNTIME_OUTPUT_NAME निष्पादन लक्ष्यों का स्थान निर्धारित करते हैं;
• LIBRARY_OUTPUT_DIRECTORY और LIBRARY_OUTPUT_NAME चर पुस्तकालयों के स्थान को निर्धारित करते हैं;
• चर ARCHIVE_OUTPUT_DIRECTORY और ARCHIVE_OUTPUT_NAME अभिलेखागार का स्थान निर्धारित करते हैं।

निष्पादन योग्य फ़ाइलों को हमेशा निष्पादन लक्ष्य माना जाता है, स्थिर पुस्तकालयों को संग्रह लक्ष्य माना जाता है, और मॉड्यूलर पुस्तकालयों को पुस्तकालय लक्ष्य माना जाता है। "गैर-डीएलएल" प्लेटफार्मों के लिए, गतिशील पुस्तकालयों को पुस्तकालय लक्ष्य माना जाता है, और "डीएलएल प्लेटफार्मों" के लिए, निष्पादन लक्ष्य। ऑब्जेक्ट लायब्रेरीज़ के लिए इस तरह के चर प्रदान नहीं किए जाते हैं, क्योंकि इस तरह की लाइब्रेरी CMakeFiles निर्देशिका के आंतों में उत्पन्न होती हैं।

यह ध्यान रखना महत्वपूर्ण है कि Cygwin सहित सभी विंडोज-आधारित प्लेटफार्मों को "DLL प्लेटफॉर्म" माना जाता है।

लाइब्रेरी लेआउट

target_link_libraries लाइब्रेरी कमांड उपलब्ध कराई गई अन्य पुस्तकालयों के साथ target_link_libraries पुस्तकालय या निष्पादन योग्य target_link_libraries । इस आदेश के लिए पहला तर्क add_executable या add_library द्वारा उत्पन्न लक्ष्य का नाम है, और बाद के तर्क पुस्तकालय लक्ष्य या पुस्तकालयों के लिए पूर्ण पथ के नाम हैं। एक उदाहरण:

 #    "MyExecutable"  #  "JsonParser", "SocketFactory"  "BrowserInvoker": target_link_libraries(MyExecutable JsonParser SocketFactory BrowserInvoker) 

यह ध्यान देने योग्य है कि मॉड्यूलर पुस्तकालयों को निष्पादन योग्य फ़ाइलों या अन्य पुस्तकालयों के साथ जोड़ा नहीं जा सकता है, क्योंकि वे निष्पादन तकनीकों के लिए लोड करने के लिए पूरी तरह से हैं।

लक्ष्यों के साथ काम करें

जैसा कि टिप्पणियों में उल्लेख किया गया है, सीएमके में लक्ष्य भी मैनुअल हेरफेर के अधीन हैं, हालांकि बहुत सीमित हैं।

प्रोजेक्ट असेंबली प्रक्रिया को सेट करने के लिए डिज़ाइन किए गए लक्ष्यों के गुणों को नियंत्रित करना संभव है। get_target_property कमांड दिए गए वैरिएबल को लक्ष्य प्रॉपर्टी का मान get_target_property । यह उदाहरण स्क्रीन पर C_STANDARD लक्ष्य के C_STANDARD गुण का मान प्रदर्शित करता है:

 #   "VALUE"   "C_STANDARD": get_target_property(VALUE MyTarget C_STANDARD) #      : message("'C_STANDARD' property is equal to [${VALUE}]") 

set_target_properties कमांड निर्दिष्ट लक्ष्य गुणों को निर्दिष्ट मानों पर सेट करता है। यह कमांड उन लक्ष्यों की एक सूची को स्वीकार करता है जिसके लिए संपत्ति मान निर्धारित किए जाएंगे, और फिर कीवर्ड PROPERTIES , इसके बाद प्रपत्र की एक सूची < > < > :

 #   'C_STANDARD'  "11", #   'C_STANDARD_REQUIRED'  "ON": set_target_properties(MyTarget PROPERTIES C_STANDARD 11 C_STANDARD_REQUIRED ON) 

ऊपर दिया गया उदाहरण MyTarget लक्ष्य गुणों को सेट करता है जो संकलन प्रक्रिया को प्रभावित करते हैं, अर्थात्: MyTarget लक्ष्य को संकलित करते MyTarget CMake को C11 मानक का उपयोग करने के लिए संकलक की MyTarget होगी। सभी ज्ञात लक्ष्य संपत्ति का नामकरण इस पृष्ठ पर सूचीबद्ध है।

if(TARGET <TargetName>) निर्माण का उपयोग करके पहले से परिभाषित लक्ष्यों को सत्यापित करना संभव है:

 #  "The target was defined!"   "MyTarget"  , #    "The target was not defined!": if(TARGET MyTarget) message("The target was defined!") else() message("The target was not defined!") endif() 

उपप्रोजेक्ट जोड़ना

add_subdirectory कमांड CMake को निर्दिष्ट add_subdirectory फ़ाइल को तुरंत संसाधित करने का संकेत देता है। नीचे दिया गया उदाहरण वर्णित तंत्र के अनुप्रयोग को प्रदर्शित करता है:

 #   "subLibrary"    , #       "subLibrary/build": add_subdirectory(subLibrary subLibrary/build) 

इस उदाहरण में, add_subdirectory कमांड के लिए पहला तर्क उप- add_subdirectory , और दूसरा तर्क वैकल्पिक है और इसमें शामिल CMakeCache.txt (उदाहरण के लिए, CMakeCache.txt और cmake_install.cmake ) की उत्पन्न फ़ाइलों के लिए इच्छित फ़ोल्डर के बारे में CMake को सूचित करता है।

यह ध्यान देने योग्य है कि पैरेंट स्कोप से सभी वेरिएबल्स को अतिरिक्त डायरेक्टरी द्वारा विरासत में मिला है, और इस डाइरेक्टरी में परिभाषित और पुनर्परिभाषित सभी वेरिएबल केवल इसे दिखाई देंगे (यदि कीवर्ड PARENT_SCOPE set कमांड तर्क द्वारा निर्दिष्ट नहीं किया PARENT_SCOPE )। पिछले लेख में टिप्पणियों में इस विशेषता का उल्लेख किया गया था।

पैकेज खोज

find_package कमांड बाहरी प्रोजेक्ट की सेटिंग ढूंढता है और लोड करता है। ज्यादातर मामलों में, इसे बाहरी पुस्तकालयों जैसे बूस्ट और जीएसएल के बाद के लिंकिंग के लिए उपयोग किया जाता है। यह उदाहरण वर्णित कमांड को GSL लाइब्रेरी और फिर लिंक के लिए खोज करने के लिए कहता है:

 #     "GSL": find_package(GSL 2.5 REQUIRED) #      "GSL": target_link_libraries(MyExecutable GSL::gsl) #      "GSL": target_include_directories(MyExecutable ${GSL_INCLUDE_DIRS}) 

उपरोक्त उदाहरण में, find_package कमांड पैकेज के नाम को find_package पहले तर्क के रूप में स्वीकार करता है, और फिर आवश्यक संस्करण। REQUIRED विकल्प न मिलने पर घातक त्रुटि को प्रिंट करना और सीएमके को समाप्त करना आवश्यक है। विपरीत QUIET विकल्प है, जिसके लिए सीएमके को अपना काम जारी रखने की आवश्यकता है, भले ही पैकेज नहीं मिला हो।

अगला, MyExecutable GSL लाइब्रेरी से MyExecutable GSL::gsl वैरिएबल का उपयोग करके MyExecutable कमांड के साथ जुड़ा हुआ target_link_libraries , जो पहले से संकलित GSL के स्थान को एन्क्रिप्ट करता है।

अंत में, target_include_directories लाइब्रेरी हेडर फ़ाइलों के स्थान के बारे में संकलक को सूचित करते हुए target_include_directories कमांड को target_include_directories । कृपया ध्यान दें कि GSL_INCLUDE_DIRS चर का उपयोग मेरे द्वारा वर्णित हेडरों GSL_INCLUDE_DIRS स्थान को GSL_INCLUDE_DIRS करने के लिए किया जाता है (यह आयातित पैकेज सेटिंग्स का एक उदाहरण है)।

यदि आप QUIET विकल्प निर्दिष्ट करते हैं तो आप शायद पैकेज खोज के परिणाम की जांच करना चाहते हैं। यह <PackageName>_FOUND जाँच करके किया जा सकता है, जो find_package कमांड के find_package होने के बाद स्वचालित रूप से निर्धारित होता है। उदाहरण के लिए, यदि आप GSL सेटिंग्स को सफलतापूर्वक अपनी परियोजना में आयात करते हैं, तो GSL_FOUND चर सच हो जाएगा।

सामान्य तौर पर, find_package कमांड में लॉन्च के दो फ्लेवर होते हैं: मॉड्यूलर और कॉन्फ़िगरेशन। ऊपर दिए गए उदाहरण ने एक मॉड्यूलर रूप लागू किया। इसका मतलब यह है कि जब कमांड को बुलाया जाता है, तो CMake फॉर्म की एक स्क्रिप्ट फ़ाइल खोजता है Find<PackageName>.cmake को CMAKE_MODULE_PATH निर्देशिका में खोजें, और फिर इसे लॉन्च करता है और सभी आवश्यक सेटिंग्स आयात करता है (इस मामले में, CMake ने मानक FindGSL.cmake फ़ाइल लॉन्च की है)।

हेडर शामिल करने के तरीके

आप दो आदेशों का उपयोग करके शामिल हेडरों के स्थान के बारे में संकलक को सूचित कर सकते हैं: include_directories और target_include_directories । आप तय करते हैं कि किसका उपयोग करना है, हालांकि, यह उनके बीच कुछ अंतरों पर विचार करने के लायक है (विचार टिप्पणियों में सुझाया गया है)।

include_directories आदेश निर्देशिका के दायरे को प्रभावित करता है। इसका मतलब यह है कि इस कमांड द्वारा निर्दिष्ट सभी हेडर निर्देशिकाओं का उपयोग वर्तमान CMakeLists.txt सभी उद्देश्यों के लिए किया जाएगा, साथ ही CMakeLists.txt लिए भी ( add_subdirectory देखें)।

target_include_directories आदेश target_include_directories पहले तर्क द्वारा निर्दिष्ट लक्ष्य को प्रभावित करता है, और अन्य लक्ष्यों को प्रभावित नहीं करता है। नीचे दिए गए उदाहरण में दो आज्ञाओं के बीच अंतर प्रदर्शित किया गया है:

 add_executable(RequestGenerator RequestGenerator.c) add_executable(ResponseGenerator ResponseGenerator.c) #     "RequestGenerator": target_include_directories(RequestGenerator headers/specific) #    "RequestGenerator"  "ResponseGenerator": include_directories(headers) 

टिप्पणियों में यह उल्लेख किया गया है कि आधुनिक परियोजनाओं में link_libraries और link_libraries का उपयोग अवांछनीय है। एक विकल्प target_include_directories और target_link_libraries जो केवल विशिष्ट लक्ष्यों पर कार्य करते हैं, और पूरे वर्तमान दायरे पर नहीं।

परियोजना स्थापना

install कमांड आपके प्रोजेक्ट के लिए इंस्टॉलेशन नियम बनाता है। यह कमांड लक्ष्य, फाइल, फोल्डर और बहुत कुछ के साथ काम करने में सक्षम है। सबसे पहले, लक्ष्य निर्धारित करने पर विचार करें।

लक्ष्य निर्धारित करने के लिए, आपको TARGETS कीवर्ड को वर्णित फ़ंक्शन के पहले तर्क के रूप में पास करना होगा, उसके बाद सेट किए जाने वाले लक्ष्यों की एक सूची और उसके बाद DESTINATION कीवर्ड उस निर्देशिका के स्थान के साथ जिसमें ये लक्ष्य निर्धारित किए जाएंगे। यह उदाहरण एक विशिष्ट लक्ष्य सेटिंग प्रदर्शित करता है:

 #   "TimePrinter"  "DataScanner"   "bin": install(TARGETS TimePrinter DataScanner DESTINATION bin) 

फ़ाइलों की स्थापना का वर्णन करने के लिए प्रक्रिया समान है, सिवाय इसके कि TARGETS कीवर्ड के बजाय FILES निर्दिष्ट करना होगा। फ़ाइलों की स्थापना का प्रदर्शन करने वाला एक उदाहरण:

 #   "DataCache.txt"  "MessageLog.txt"   "~/": install(FILES DataCache.txt MessageLog.txt DESTINATION ~/) 

फ़ोल्डर्स की स्थापना का वर्णन करने के लिए प्रक्रिया समान है, सिवाय इसके कि आपको FILES कीवर्ड के बजाय DIRECTORY को निर्दिष्ट करना होगा। यह ध्यान रखना महत्वपूर्ण है कि स्थापना के दौरान फ़ोल्डर की संपूर्ण सामग्री की प्रतिलिपि बनाई जाएगी, और न केवल इसका नाम। फ़ोल्डर स्थापित करने का एक उदाहरण इस प्रकार है:

 #   "MessageCollection"  "CoreFiles"   "~/": install(DIRECTORY MessageCollection CoreFiles DESTINATION ~/) 

अपनी सभी फ़ाइलों के CMake प्रसंस्करण को पूरा करने के बाद, आप sudo checkinstall (यदि CMake मेकफाइल उत्पन्न करता है) के साथ सभी वर्णित वस्तुओं को स्थापित कर सकते हैं, या CMake का समर्थन करने वाले एकीकृत विकास वातावरण के साथ यह क्रिया कर सकते हैं।

परियोजना का दृश्य उदाहरण

यह गाइड CMake बिल्ड सिस्टम का उपयोग करने की वास्तविक दुनिया के उदाहरण का प्रदर्शन किए बिना पूरा नहीं होगा। केवल निर्माण प्रणाली के रूप में CMake का उपयोग करते हुए एक सरल परियोजना आरेख पर विचार करें:

 + MyProject - CMakeLists.txt - Defines.h - StartProgram.c + core - CMakeLists.txt - Core.h - ProcessInvoker.c - SystemManager.c 

मुख्य असेंबली फ़ाइल CMakeLists.txt पूरे कार्यक्रम के संकलन का वर्णन करती है: सबसे पहले, add_executable कमांड को add_executable है जो निष्पादन योग्य फ़ाइल को संकलित करता है, फिर add_subdirectory कमांड को add_subdirectory , जो add_subdirectory के प्रसंस्करण को उत्तेजित करता है, और अंत में, निष्पादन योग्य फ़ाइल संकलित लाइब्रेरी से जुड़ी होती है:

 #    CMake: cmake_minimum_required(VERSION 3.0) #   : project(MyProgram VERSION 1.0.0 LANGUAGES C) #      "MyProgram": add_executable(MyProgram StartProgram.c) #    "core/CMakeFiles.txt": add_subdirectory(core) #    "MyProgram"  #    "MyProgramCore": target_link_libraries(MyProgram MyProgramCore) #    "MyProgram"   "bin": install(TARGETS MyProgram DESTINATION bin) 

core/CMakeLists.txt फ़ाइल को मुख्य असेंबली फ़ाइल द्वारा बुलाया जाता है और निष्पादन योग्य फ़ाइल के साथ जोड़ने के लिए MyProgramCore स्थिर लाइब्रेरी का संकलन करता है:

 #    CMake: cmake_minimum_required(VERSION 3.0) #      "MyProgramCore": add_library(MyProgramCore STATIC ProcessInvoker.c SystemManager.c) 

cmake . && make && sudo checkinstall कमांड की एक श्रृंखला के बाद cmake . && make && sudo checkinstall cmake . && make && sudo checkinstall CMake बिल्ड सिस्टम सफलतापूर्वक पूरा होता है। पहला कमांड प्रोजेक्ट के रूट डायरेक्टरी में CMakeLists.txt फाइल को प्रोसेस करना शुरू करता है, दूसरा कमांड अंत में आवश्यक बाइनरी फाइलों को संकलित करता है, और तीसरा कमांड सिस्टम में संकलित MyProgram स्थापित करता है।

निष्कर्ष

अब आप अपने स्वयं के लिखने और अन्य लोगों की सीएमके फ़ाइलों को समझने में सक्षम हैं, और आप आधिकारिक वेबसाइट पर अन्य तंत्रों के बारे में विस्तार से पढ़ सकते हैं।

इस गाइड का अगला लेख CMake का उपयोग करके परीक्षण और पैकेज बनाने पर केंद्रित होगा और एक सप्ताह में जारी किया जाएगा। जल्द मिलते हैं!