परियोजनाओं में स्वचालित रूप से मेकफाइल्स उत्पन्न करने के लिए Cmake का उपयोग करना

परिचय बहुत अच्छा है, क्योंकि यह विस्तार से बताता है कि सेमीक की आवश्यकता क्यों है। आप तुरंत कटौती के तहत कर सकते हैं, यदि आप पहले से ही जानते हैं।

प्रविष्टि

अपने हाथों से एक परियोजना को संकलित करना समय की बर्बादी है। यह वास्तव में एक स्वयंसिद्ध है और जो लोग कार्यक्रम जानते हैं, वे इसके बारे में जानते हैं। लेकिन सब कुछ स्वचालित रूप से संकलित करने के लिए, आपको नियम निर्धारित करने की आवश्यकता है, है ना? अक्सर और पुराने तरीके से वे खिड़कियों के लिए * निक्स या कुछ एनएमके के लिए मेकफाइल का उपयोग करते हैं।
हालाँकि मैं एक साल से अधिक समय से प्रोग्रामिंग कर रहा हूं, मैंने अपने हाथों से मेकफाइल पर आधारित परियोजनाओं के सरल ऑटो-एसेम्बलर्स बनाए हैं, लेकिन यह थोड़ा भूलने के लायक है और आपको इस चतुर योजना को फिर से सीखना होगा। मूल रूप से, आपको किसी एक सिस्टम के लिए डिज़ाइन किए गए प्रोजेक्ट्स करने होंगे, चाहे वह लिनक्स या खिड़कियां हों, और अक्सर आपस में क्रॉस-संकलित न हों। मेकफिल पोर्टेबिलिटी के लिए, ऑटोमेटेक और ऑटोजेन का उपयोग किया जाता है , लेकिन उनका सिंटैक्स और भी अधिक भ्रामक होता है। मैं यह नहीं कहूंगा कि पसंद आदर्श है, लेकिन खुद के लिए मैंने सीमेक पर स्विच करने का फैसला किया, क्योंकि यह सब कुछ उपलब्ध है। यह मुझे अधिक मानव-पठनीय लगा। मैं मूल बातें समझाने की कोशिश करूँगा। आप नियमों को शब्दों के साथ लिखते हैं, और उनसे एक मेकफाइल उत्पन्न होता है, जिसे आप पहले से ही मानक तरीके से चलाते हैं।

शैक्षिक कार्यक्रम

इसकी आवश्यकता क्यों है? ताकि जब दूसरी मशीन में स्थानांतरित किया जाए, तो अलग-अलग रास्तों के साथ, आप मेकफाइल में कुछ भी ठीक किए बिना दो कमांड के साथ एक प्रोजेक्ट लगाते हैं। लेकिन क्या कॉन्फ़िगर है? यह एक विकल्प है। और कॉन्फ़िगर क्रॉस-प्लेटफ़ॉर्म नहीं है, इसकी पीढ़ी के लिए आपको ऑटोकॉन्फ़ / ऑटोजेन की आवश्यकता होती है, जिसके लिए अभी भी नियमों का एक सेट है। केवल लाभ? ऑटो-जनरेट किए गए मेकफाइल के साथ संकलन करना पुरानी पद्धति की तुलना में थोड़ा धीमा है। उदाहरण के लिए, KDE-4 एक आधिकारिक रिलीज़ टूल है ।

शुरुआत हो रही है

वर्तमान ट्यूटोरियल में, मैं सबसे सरल C ++ प्रोजेक्ट टेम्पलेट के बारे में बात करूंगा जिसे लिनक्स पर संकलित किया जाना चाहिए। कोई पोर्टेबिलिटी पर चर्चा नहीं की जाएगी, अलग-अलग कंपाइलर को सौंपा नहीं जाएगा, आदि। यह एक लेख में फिट नहीं होगा, और सम्मेलनों का ढेर शुरुआती को बहुत भ्रमित करेगा।
सबसे पहले, cmake पर परियोजनाओं की गुप्त रूप से स्वीकृत संरचना के बारे में। आमतौर पर, प्रोजेक्ट की जड़ src फ़ोल्डर है (बंद स्रोत के लिए), शामिल (सार्वजनिक हेडर के लिए), लिब (प्लग-इन लाइब्रेरी के लिए, यदि वे सिस्टम लाइब्रेरी नहीं हैं), एक खाली बिल्ड फ़ोल्डर (यदि नहीं, तो इसे बनाएं), मैं नहीं बनाऊंगा बिन (या बाहर, बायनेरिज़ के लिए) जोड़ें। इसके लिए रूट में AUTHOTS, COPYING, INSTALL, NEWS, README, ChangeLo g फाइलों की मौजूदगी भी आवश्यक है। वे खाली हो सकते हैं, लेकिन उपलब्धता की आवश्यकता है। एक वैकल्पिक config.h.in फ़ाइल (उस पर बाद में और अधिक) हो सकती है। Cmake कॉन्फ़िगरेशन फाइलें प्रत्येक में CMakeLists.txt नामक फ़ोल्डर में हैं। यह नाम cmake द्वारा गढ़ा गया था और नहीं बदलता है।
प्रलेखन को शुरू में समझना मुश्किल है, हालांकि पूर्ण। यह एक और माइनस है। लेकिन ऑटोटूलस की तुलना में ...
प्रोजेक्ट फ़ाइल प्रकार cmake की सूची उत्पन्न कर सकते हैं:


मान लीजिए हमारे पास कुछ source.cpp हैं जिनसे हम सॉफ्टवेयर प्राप्त करते हैं - इसे src फ़ोल्डर में डालें। लेकिन हमारे पास एक परियोजना है, इसलिए कुछ और फाइलें core.cpp, core.hpp, common.hpp, types.hpp हैं , जिन्हें हमने src में भी रखा है और उदाहरण के लिए, कुछ लाइब्रेरी की जरूरत है। हमने स्रोत का पता लगाया, परियोजना के विवरण के लिए आगे बढ़ें और ऑटो-संकलन के लिए इसे तैयार कर रहे हैं।

यह सब प्रोजेक्ट रूट में CMakeLists.txt फ़ाइल बनाने के साथ शुरू होता है। Cmake नियम एक स्क्रिप्टिंग भाषा के समान है, जावास्क्रिप्ट और php के बीच एक क्रॉस है। केवल बहुत आसान है। इसमें स्थितियां, फ़ंक्शन, चर, स्थिरांक, प्लग-इन हैं।

मैं उन्हें समझाने के लिए CMakeLists.txt फाइल को कई हिस्सों में तोड़ूंगा। भाग 1:

#     cmake_minimum_required (VERSION 2.6) cmake_policy(SET CMP0011 NEW) cmake_policy(SET CMP0003 OLD) OPTION(WITH_DEBUG_MODE "Build with debug mode" ON) if ( NOT UNIX ) message (FATAL_ERROR "Not Unix!") endif () 

यहाँ cmake_minimum_required संस्करण चेक फ़ंक्शन है।
ऑपरेटरों को इस तरह लिखा जाता है जैसे () उद्घाटन और एंडिफ () समापन। फ़ॉरचैट () और एंडफ़ॉरच () के समान।
संदेश फ़ंक्शन हमारे संदेश को प्रदर्शित करता है। मैंने संदेश के प्रकार को इंगित करने के लिए FATAL_ERROR ध्वज का उपयोग किया।
यह भी ध्यान दें कि कोई अर्धविराम (;) कमांड के अंत में नहीं रखा गया है। एक पंक्ति है - एक आदेश। कोष्ठकों को केवल पठनीयता के लिए ऑपरेटरों से दूर ले जाया जाता है।
प्रत्येक टीम के पास आमतौर पर पैरामीटर सेट करने के लिए कई विकल्प होते हैं, इसलिए मैनुअल को देखे बिना ऐसा नहीं करता है।
एक त्वरित परिचय और एक सरल उदाहरण प्रलेखन में हैं, लेकिन मेरी राय में बहुत सरल हैं।

भाग 2:

 message ("Starting cmake") #    ,     ,      include (myproj.cmake) #    set (PROJECT myproj) #         set (LIBRARIES) #          foreach (LIBRARY ${LIBRARIES}) find_library("${LIBRARY}_FOUND" ${LIBRARY}) message(STATUS "Check the ${LIBRARY} is installed: " ${${LIBRARY}_FOUND}) if ( "${${LIBRARY}_FOUND}" STREQUAL "${LIBRARY}_FOUND-NOTFOUND" ) message(STATUS "Adding library sources") add_subdirectory (../${LIBRARY} lib/${LIBRARY}) endif () endforeach () #     set (TARGETS "") set (HEADERS "") message ( STATUS "SOURCES: ${SOURCES}") add_subdirectory (src) 

सेट () फ़ंक्शन वैरिएबल बनाता या ओवरराइट करता है। यदि कोई मूल्य नहीं है, तो चर खाली हो जाएगा। यहाँ सेट किए गए चरों का नाम इस अर्थ के अनुसार रखा गया है कि वे पीढ़ी में चलते हैं।
शामिल () वर्तमान स्थान में कॉन्फ़िगरेशन के एक टुकड़े के साथ एक बाहरी फ़ाइल शामिल है। कोई स्पष्टीकरण नहीं है।
और add_subdirectory (src) इंगित करता है कि प्रोजेक्ट के मेकफाइल का निर्माण जारी रखने के लिए कहां।

यदि केवल सामान्य नियम यहां सेट किए गए थे, तो CMakeLists.txt में src डायरेक्टरी के अंदर, विशिष्ट स्रोत फ़ाइलों के संयोजन के लिए विकल्प सेट किए जाएंगे।

अभी तक उल्लेख नहीं cmake_policy ()। मैंने फैसला किया कि अब मुझे इसकी समझ नहीं है। इसे यहां लटका दें © यह सिर्फ असेंबली को आसान बनाता है।
फ़ॉरच () लूप और लाइब्रेरी का वर्णन बाद में किया जाएगा। अभी के लिए छोड़ दें।

तो एक अलग cmake फ़ाइल में क्या निकाला गया था? आइए देखें:

 set ("${PROJECT}_BINARY_DIR" bin) set ("${PROJECT}_SOURCE_DIR" src:include) set ("${PROJECT}_LIB_DIR" lib) set (CMAKE_INCLUDE_PATH ${${PROJECT}_SOURCE_DIR}) set (CMAKE_LIBRARY_PATH ${${PROJECT}_LIB_DIR}) set (EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/${${PROJECT}_BINARY_DIR}) set (CMAKE_VERBOSE_MAKEFILE ON) set (CMAKE_BUILD_TYPE Debug) set (ERR_NO_UNIX "Cannot build on non Unix systems") if ( WITH_DEBUG_MODE ) ADD_DEFINITIONS( -DMY_DEBUG_MODE=1) endif() if ( CMAKE_COMPILER_IS_GNUCXX ) set(MY_CXX_FLAGS "-Wall -std=c++0x -fmessage-length=0 -v -L/usr/local/lib -L/usr/lib") set(CMAKE_CXX_FLAGS "-O0 ${MY_CXX_FLAGS}") #         .    . #set(CMAKE_CXX_FLAGS_DEBUG "-g -O0 -fno-reorder-blocks -fno-schedule-insns -fno-inline") #set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG") else () message (FATAL_ERROR ${ERR_NO_UNIX}) endif () 

हम देखते हैं कि सेट () $ {नाम} के रूप में एक अजीब (या पहले से परिचित) निर्माण का उपयोग करता है - यह उसी सेट का उपयोग करके पहले से परिभाषित चर का विकल्प देता है () या खुद को सेमी करें (सभी cmake परिभाषित चर दस्तावेज में हैं)। उदाहरण के लिए, $ {PROJECT} पहले से परिभाषित प्रॉजेक्ट चर से myproj का मान डालेगा।
Src: प्रविष्टि में सिर्फ एक स्ट्रिंग है, जिसका अर्थ है कि लिनक्स में पथों की गणना है (वे एक बृहदान्त्र द्वारा अलग किए जाते हैं, और अर्धविराम नहीं)।
पहली तीन पंक्तियाँ मेरे द्वारा निर्धारित चर हैं। और यहाँ cmake द्वारा आवश्यक आवश्यक चर हैं। उन्हें स्पष्ट रूप से छोड़ा जा सकता है, उन्हें पहले से ही लॉन्च के साथ परिभाषित किया गया है, लेकिन वे इंगित नहीं करेंगे कि आप इस फ़ोल्डर संरचना के साथ कहां चाहते हैं।

कभी-कभी आपको अन्य चर के आधार पर एक चर नाम बनाने की आवश्यकता होती है, और यह संभव है: $ {$ {PROJECT} _SOURCE_DIR}। सबसे पहले, PROJECT को $ {myproj_SOURCE_DIR} प्राप्त करने के लिए नियुक्त किया गया है, जो पहले से ही शुरुआत में परिभाषित है। नतीजतन, इसका मूल्य होगा। ये सभी आवश्यक कठिनाइयाँ हैं, ताकि यदि प्रोजेक्ट का नाम myproj से सुपरपॉपर में बदल जाए, तो आपको चर के नाम और अन्य चीजों को बदलते हुए कोड में नहीं चढ़ना पड़ेगा।

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

if (with_DEBUG_MODE) - एक विशेष प्रकार का चर है जो with_ से शुरू होता है। वे विकल्प () फ़ंक्शन, एक फ़ंक्शन का उपयोग करके बनाए जाते हैं जो उपयोगकर्ता विकल्पों को परिभाषित करता है (यह बहुत शुरुआत में कोड में था)। ये चर केवल दो चालू या बंद मूल्यों को स्वीकार करते हैं और उदाहरण के लिए बूलियन मूल्यों के रूप में उपयोग किया जा सकता है। और ADD_DEFINITION (-DMY_DEBUG_MODE = 1) डीबग मोड सक्षम होने पर कंपाइलर में -DMY_DEBUG_MODE विकल्प जोड़ेगा। C ++ कंपाइलर (इस मामले में) के लिए, इसका मतलब होगा परिभाषित जोड़ना।

स्रोत कोड के साथ कार्य करना

तो हम src फ़ोल्डर में आए। इसमें CMakeLists.txt भी आवश्यक है, हम इस पर अधिक विस्तार से विचार करेंगे।

 set ("${PROJECT}_VERSION_MAJ" 0) set ("${PROJECT}_VERSION_MIN" 1) set ("${PROJECT}_VERSION_A" 1) set ("${PROJECT}_VERSION_B" 1) set ("${PROJECT}_VERSION" ${${PROJECT}_VERSION_MAJ}0${${PROJECT}_VERSION_MIN}0${${PROJECT}_VERSION_A}0${${PROJECT}_VERSION_B}) message(STATUS ${${PROJECT}_VERSION}) #    set (MAIN_SOURCES source.cpp ) #    set (PRIVATE_CLASSES core ) #   ,    - SET (HEADERS_ONLY types common ) #   set (PUBLIC_CLASSES) #     set (ADDITIONAL_LIBRARIES stdc++ pthread ) set (PUBLIC_HEADERS) set (SOURCES) foreach (class ${PRIVATE_CLASSES}) LIST (APPEND SOURCES ${class}.cpp) LIST (APPEND HEADERS ${class}.hpp) endforeach () foreach (class ${HEADERS_ONLY}) LIST (APPEND HEADERS ${class}.hpp) endforeach () foreach (class ${PUBLIC_CLASSES}) LIST (APPEND SOURCES ${class}.cpp) LIST (APPEND HEADERS ../include/${PROJECT}/${class}.hpp) LIST (APPEND PUBLIC_HEADERS ../include/${PROJECT}/${class}.hpp) endforeach () add_executable (${PROJECT} ${MAIN_SOURCES} ${SOURCES}) target_link_libraries (${PROJECT} ${ADDITIONAL_LIBRARIES}) set_target_properties(${PROJECT} PROPERTIES VERSION "${${PROJECT}_VERSION}" SOVERSION "0") INSTALL ( TARGETS ${PROJECT} DESTINATION lib${LIB_SUFFIX} ) INSTALL ( FILES ${PUBLIC_HEADERS} DESTINATION include/${PROJECT} ) 

विशिष्ट फाइलें और उनकी विधानसभा यहां दर्ज की गई हैं। सबसे पहले, हमने कार्यक्रम का संस्करण निर्धारित किया। अगला, हम स्रोत कोड के समूहों (या जैसा कि उन्हें यहां, सूची में बुलाया जाता है) को परिभाषित करते हैं, सभी नाम एक स्थान के साथ लिखे गए हैं। MAIN_SOURCES - एक मुख्य स्रोत, PRIVATE_CLASSES - स्रोत युग्मों की एक सूची (source.cpp-header.hpp एक सामान्य नाम के साथ), PUBLIC_CLASSES - इस परियोजना के लिए रिक्त, HEADERS_ONLY - केवल हेडर फ़ाइलों की सूची, ADDITIONAL_LIBRARIES - पुस्तकालयों C ++ परियोजना से जुड़े।

निम्नलिखित चक्र हेडर और स्रोत कोड की सूचियों को एक प्लग करने योग्य सूची में जोड़ते हैं (मैं ध्यान देता हूं कि पिछले विभाजन को सार्वजनिक और छिपा हुआ विशुद्ध रूप से सशर्त था)। और अंत में, नियम "निष्पादन योग्य फ़ाइल में प्रोजेक्ट को इकट्ठा करता है" add_executable ()। बाइनरी को असेंबल करने के बाद, आपको target_link_lbooks () और इसका उपयोग करके लिंक लाइब्रेरी को इसमें जोड़ना होगा। परियोजना के नियम परिभाषित हैं।
सुविधा के लिए, आप इंस्टॉल () का उपयोग करके इंस्टॉलेशन-इंस्टॉलेशन नियम जोड़ सकते हैं।

हम बिल्ड डायरेक्टरी में जाते हैं, जो प्रोजेक्ट के रूट पर है, और रन करता है

cmake ।।

कमांड लाइन से। यदि सब कुछ ठीक हो गया (और इसे अच्छी तरह से जाना चाहिए), तो हम प्राप्त करते हैं

- कॉन्फ़िगर किया जा रहा है
- किया हुआ
- बिल्ड फ़ाइलों को लिखा गया है: / घर / उपयोगकर्ता नाम / tmp / fooproj / build

और साइड मेकफाइल द्वारा
फिर सामान्य तरीके से

मेकअप

एक निष्कर्ष के बजाय

मुझे यह विधि सरल और कॉन्फ़िगर करने की तुलना में अधिक सुविधाजनक लगी। यदि आप अचानक इस बारे में बहस करना चाहते हैं, तो मैं टिप्पणी करने से बचना चाहूंगा। क्योंकि क्यों?
यदि आपने कुछ बदला है और cmake त्रुटियां देता है, तो पहले पूरी फ़ाइल कैश को बिल्ड डायरेक्टरी (लगभग सब कुछ बोल रहा है) या कम से कम CMakeCache.txt को उसी बिल्ड डायरेक्टरी से हटा दें।

ट्यूटोरियल में क्या विचार नहीं किया गया था:
1) क्यूटी या बूस्ट पुस्तकालयों को जोड़ना
2) स्थापित पुस्तकालयों के लिए खोजें
3) बहु मंच
4) विभिन्न संकलक के लिए विकल्प

प्रलेखन:

1) प्रलेखन का मुख्य पृष्ठ
2) संस्करण 2.8.9 के लिए प्रलेखन
3) इस अपमान का स्रोत जुड़ा हुआ है ।