C / C ++ प्रोजेक्ट बनाने के लिए हम GYP का उपयोग करते हैं

परिचय

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

प्रागितिहास

GYP को एक विशिष्ट प्रोजेक्ट - Chrome / Chromium ब्राउज़र बनाने के लिए डिज़ाइन किया गया था । आपके उपकरण को विकसित करने के निर्णय से बहुत विवाद हुआ, बहुतों को समझ में नहीं आया (शायद अभी भी समझ में नहीं आया है) अपने स्वयं के "साइकिल" का आविष्कार क्यों करें। हालांकि, GYP एक काफी लोकप्रिय उपकरण बन गया है, और अब इसका उपयोग क्रोमियम के बुनियादी ढांचे के बाहर किया जाता है, उदाहरण के लिए, V8 और देशी नोड्स मॉड्यूल बनाने के लिए।

सीएमके से समानताएं और अंतर

GYP के रचनाकारों ने CMake के लेखकों के रूप में लगभग एक ही लक्ष्य का पीछा किया: एक क्रॉस-प्लेटफ़ॉर्म सिस्टम लागू करें जो आपको बिल्ड सिस्टम के लिए विभिन्न प्रोजेक्ट फ़ाइलों और स्क्रिप्ट के निर्माण के लिए उपयुक्त उच्च-स्तरीय भाषा में निर्माण प्रक्रिया का वर्णन करने की अनुमति देता है। GYP वर्तमान में GNU मेक , SCons , निंजा , एक्लिप्स (CDT), विजुअलस्टडियो और Xcode का समर्थन करता है।

GYP और CMake के बीच मुख्य अंतर (मेरी राय में):

• परियोजना की संरचना का वर्णन करने के लिए बहुत अधिक सुखद और समझने योग्य भाषा। कृपया ध्यान दें कि GYP फ़ाइल संरचना को परिभाषित करती है, और CMakeLists.txt की तरह कार्यों के अनुक्रम का वर्णन नहीं करती है । सब कुछ बहुत सहज और घोषणात्मक है। इसके अलावा, यह प्रारूप स्वचालित प्रसंस्करण और विश्लेषण के लिए बहुत सुविधाजनक है।
• व्यक्तिगत मॉड्यूल से परियोजनाओं की रचना के लिए सुविधाजनक उपकरण। GYP फ़ाइल में घोषित लक्ष्य, GYP की अन्य फ़ाइलों के लक्ष्य को निर्भरता घोषित कर सकता है।
• आईडीई सुविधाओं के साथ सख्त एकीकरण। GYP आपको उन लक्ष्यों के गुणों की घोषणा करने की अनुमति देता है, जिन्हें ध्यान में रखा जाएगा, उदाहरण के लिए, केवल वीएस परियोजनाओं के लिए, और अन्य प्रोजेक्ट फ़ाइलों के लिए अनदेखा किया गया।
• GYP को पायथन में लागू किया गया है और इसमें काफी कॉम्पैक्ट, संरचित और पठनीय स्रोत कोड है (जो कि सीएमके के बारे में कहना मेरे लिए कठिन है)। यदि, उदाहरण के लिए, मुझे एक नए प्रकार की प्रोजेक्ट फ़ाइलों (उदाहरण के लिए ईडीबी के लिए स्टब्स) के जनरेटर को लागू करने की आवश्यकता है, तो मैं बिना किसी हिचकिचाहट के आधार के रूप में जीवाईपी को पसंद करूंगा।

GYP और CMake के बीच अंतर के बारे में जानने के इच्छुक लोग पहली बार आधिकारिक विकी पर संबंधित पृष्ठ पर जा सकते हैं। वहाँ आप डेवलपर्स की एक गर्म झड़प के साथ मेलिंग सूची के लिए एक लिंक पा सकते हैं।

स्थापना

स्थापना को पायथन की आवश्यकता होगी, अधिमानतः संस्करण 2.6 या उच्चतर। लिनक्स उपयोगकर्ताओं को इसे स्थापित करने की आवश्यकता नहीं होगी, विंडोज उपयोगकर्ता ActivePython तक पहुंच सकते हैं या आधिकारिक पायथन साइट से वितरण डाउनलोड कर सकते हैं।

मैं आधिकारिक रिपॉजिटरी से GYP के नवीनतम संस्करण का उपयोग करना पसंद करता हूं। स्रोत कोड से स्थापित करने के लिए, स्रोत कोड के साथ निर्देशिका पर जाएं और sudo python setup.py install कमांड को चलाएं। यदि आप व्यवस्थापक विशेषाधिकारों के साथ विश्व स्तर पर GYP स्थापित नहीं करना चाहते हैं, तो आप केवल GYP स्रोतों के साथ निर्देशिका को PATH पर्यावरण चर में जोड़ सकते हैं।

लोकप्रिय लिनक्स वितरण में अक्सर मानक रिपॉजिटरी में gyp पैकेज होता है (संभवतः सबसे हालिया संस्करण नहीं)।

मुझे V8 लेखकों का दृष्टिकोण भी पसंद है जो build उपनिर्देशिका में GYP के एक विशिष्ट परीक्षण किए गए संस्करण की जांच करते हैं और विभिन्न प्लेटफार्मों के लिए मेकफाइल्स उत्पन्न करने के लिए इस संस्करण का उपयोग करते हैं।

Emacs उपयोगकर्ताओं के लिए, GYP फ़ाइलों को संपादित करने के लिए एक प्लगइन उपयोगी हो सकता है।

ऐसा हुआ कि लिनक्स मेरी मशीन पर स्थापित किया गया था, इसलिए आगे का वर्णन एक लिनक्स उपयोगकर्ता के दृष्टिकोण से होगा जो अन्य प्रणालियों के उपयोगकर्ताओं को सहन करता है और उनकी आवश्यकताओं का सम्मान करता है।

एक आत्म निहित मॉड्यूल की तरह

तो, यह कार्रवाई में उपकरण दिखाने का समय है। मुझे लगता है कि कुछ लोग "हैलो वर्ल्ड" जैसे उदाहरण का उपयोग करके डेमो में रुचि रखते हैं, इसलिए एक शुरुआत के लिए हम कुछ उपयोगी मॉड्यूल के निर्माण के लिए कॉन्फ़िगरेशन का वर्णन करेंगे, उदाहरण के लिए, जीटीएस्ट लाइब्रेरी के लिए (जिसके लिए किट में एक सीएमके स्क्रिप्ट है, इसलिए जीटीएस्ट एक नमूना के रूप में दोगुना उपयोगी है। : एक जिज्ञासु पाठक दोनों विशिष्टताओं की पठनीयता का मूल्यांकन करने और उस उपकरण को चुनने में सक्षम होगा जिसे वह सबसे ज्यादा पसंद करता है)।

नीचे क्रोमियम रिपॉजिटरी में पाए गए विनिर्देश का थोड़ा सरल और छोटा संस्करण है ।

 { 'targets': [ # <-   #   { 'target_name': 'gtest', # <-   'cflags': ['-pthread'], # <-   'link_settings': { # <-   'libraries': ['-lpthread'] # <-    }, 'type': 'static_library', # <-  ,   static_library, # shared_library, executable, none 'standalone_static_library': 1, # <-     thin archive #        GYP 'sources': [ # <-    'include/gtest/gtest-death-test.h', 'include/gtest/gtest-message.h', 'include/gtest/gtest-param-test.h', 'include/gtest/gtest-printers.h', 'include/gtest/gtest-spi.h', 'include/gtest/gtest-test-part.h', 'include/gtest/gtest-typed-test.h', 'include/gtest/gtest.h', 'include/gtest/gtest_pred_impl.h', 'include/gtest/internal/gtest-death-test-internal.h', 'include/gtest/internal/gtest-filepath.h', 'include/gtest/internal/gtest-internal.h', 'include/gtest/internal/gtest-linked_ptr.h', 'include/gtest/internal/gtest-param-util-generated.h', 'include/gtest/internal/gtest-param-util.h', 'include/gtest/internal/gtest-port.h', 'include/gtest/internal/gtest-string.h', 'include/gtest/internal/gtest-tuple.h', 'include/gtest/internal/gtest-type-util.h', 'src/gtest-all.cc', 'src/gtest-death-test.cc', 'src/gtest-filepath.cc', 'src/gtest-internal-inl.h', 'src/gtest-port.cc', 'src/gtest-printers.cc', 'src/gtest-test-part.cc', 'src/gtest-typed-test.cc', 'src/gtest.cc', ], 'sources!': [ # <-     , 'src/gtest-all.cc', #      ], #  conditions 'include_dirs': [ # <-      '.', './include', ], 'conditions': [ # <-   ,   ['OS == "linux"', { #     'defines': [ 'GTEST_HAS_RTTI=0', ], 'direct_dependent_settings': { 'defines': [ 'GTEST_HAS_RTTI=0', ], }, }], ['OS=="win" and (MSVS_VERSION=="2012" or MSVS_VERSION=="2012e")', { 'defines': [ '_VARIADIC_MAX=10', ], 'direct_dependent_settings': { 'defines': [ '_VARIADIC_MAX=10', ], }, }], ], 'direct_dependent_settings': { # <- ,     , #   gtest , . .   'defines': [ # <-   'UNIT_TEST', ], 'include_dirs': [ # <-     include  'include', #     , ], #     ,  #  </path/to/this/gypfile>/include 'msvs_disabled_warnings': [4800], }, }, #   { 'target_name': 'gtest_main', 'type': 'static_library', 'standalone_static_library': 1, 'dependencies': ['gtest'], # <-   ,    #      'sources': [ 'src/gtest_main.cc', ], }, ], } 

मुझे लगता है कि यह विनिर्देश कई के लिए काफी पारदर्शी होगा (स्थितियों के साथ वर्गों के संभावित अपवाद के साथ)।

यह सभी स्रोत फ़ाइलों को सूचीबद्ध करने के लिए तुरंत आंख को पकड़ता है। यह थकाऊ और अत्यधिक क्रिया लग सकता है। GYP CMake से GLOB समकक्ष का समर्थन नहीं करता है, इसके अलावा, इस सुविधा को सचेत रूप से महसूस नहीं किया गया था। डेवलपर्स के अनुसार, GLOB की कमी से त्रुटियों की संभावना कम हो जाती है और असेंबली की "जकड़न" और प्रजनन क्षमता में वृद्धि होती है।

हेडर फ़ाइलों को भी स्रोत सूची में शामिल करने की आवश्यकता होती है, अन्यथा वे दृश्य स्टूडियो परियोजनाओं को बनाते समय बस दिखाई नहीं देंगे।

बनाने के लिए, बस निम्नलिखित कमांड चलाएँ:

 gyp --depth=. gtest.gyp #  Makefile make #  make 

Gtest.gyp फ़ाइल को संशोधित करने के बाद, मेकफाइल अगली बार आपके द्वारा बनाए make बाद स्वचालित रूप से पुनर्जीवित हो जाएगा।

विधानसभा से उत्पन्न कलाकृतियों को बाहर / BUILDTYPE निर्देशिका की उपनिर्देशिकाओं में पाया जा सकता है, डिफ़ॉल्ट बाहर / डिफ़ॉल्ट है ।

नोट : प्रोजेक्ट फ़ाइल जनरेटर ऑपरेटिंग सिस्टम (विंडोज के लिए एमएसवी, लिनक्स के लिए बनाते हैं, मैक के लिए एक्सकोड) और जीवाईपी _{जनरेटर} पर्यावरण चर के आधार पर चुना जाता है, बाद वाला पूर्ववर्ती। एक विशिष्ट जनरेटर (या एक साथ कई) शुरू करने के लिए, आपको निम्न के समान एक कमांड चलाने की आवश्यकता है:

 GYP_GENERATORS=make,scons,eclipse gyp --depth=. gtest.gyp 

दुर्भाग्य से, मैं लिनक्स के तहत scons और msvs जनरेटर के साथ समस्या हो रही है। मुझे लगता है कि अभी भी आपके प्लेटफ़ॉर्म के लिए डिफ़ॉल्ट जनरेटर का उपयोग करना उचित है (हालांकि, मैक के लिए जनरेटर को समस्याओं के बिना काम करना चाहिए)।

चर प्रतिस्थापन

GYP में वेरिएबल्स का विस्तार दो चरणों में होता है: "प्रारंभिक" चरण में, शर्तों के अंदर conditions और क्वांटिफायर के साथ घोषित चर < ; "लेट" एक पर, target_conditions अनुभाग की शर्तों की गणना और क्वांटिफायर के साथ चर > , साथ ही साथ बाहरी कमांड के आउटपुट का प्रतिस्थापन।

अधिकांश कार्यों के लिए, "प्रारंभिक" चरण के चर उपयुक्त हैं।

शुरुआती और देर के चरण के चर उपयोग के स्थान पर पहले वर्ण की दिशा में भिन्न होते हैं: <(var) - प्रारंभिक चरण (तीर बाईं ओर इंगित करता है, अर्थात, गणना पहले समय पैमाने पर होती है), >(var) - देर चरण (तीर दाईं ओर इंगित करता है)।

चर मानों की गणना दो अलग-अलग संदर्भों में की जा सकती है:

• स्ट्रिंग संदर्भ ( <(var) , >(var) ) - वैरिएबल के मान को इस प्रकार प्रतिस्थापित किया जाता है।
• सूची का संदर्भ ( <@(var) , >@(var) ) - चर का मूल्य उस सूची में एम्बेडेड है जिसमें यह गणना की जाती है (सूची के अंदर ऐसी गणना आवश्यक रूप से होनी चाहिए)।

विभिन्न संदर्भों का उपयोग करने का एक उदाहरण:

 { 'variables': { 'component_type': 'shared_library', 'public_api_headers': [ 'include/mylib.h', 'include/mylib_extra.h', ], 'private_headers': [ 'internals.h', ], }, 'targets': [ { 'target_name': 'mylib', 'type': '<(component_type)', # <-   'include_dirs': ['include'], 'sources': [ '<@(public_api_headers)', # <-  public_api_headers '<@(private_headers)', #  private_headers   'src/impl.cc', #   sources ], }, ], } 

चर जिनका मान एक सूची है उन्हें एक स्ट्रिंग संदर्भ में मूल्यांकन किया जा सकता है। गणना का परिणाम एक स्ट्रिंग होगा जिसमें रिक्त स्थान द्वारा अलग की गई सूची आइटम होंगे। इसी तरह, एक चर जिसका मान एक स्ट्रिंग है, एक सूची संदर्भ में गणना की जा सकती है। इस मामले में, एक सूची का निर्माण किया जाएगा, एक अंतरिक्ष तत्वों के विभाजक के रूप में उपयोग किया जाएगा।

कभी-कभी यह आवश्यक होता है कि किसी बाहरी कमांड का उपयोग करके वैरिएबल के मान की गणना की जाए, इसके लिए कंस्ट्रक्शन <!(cmd) और <!@(cmd) का उपयोग किया जाता है:

 'variables' : [ 'foo': '<!(echo Build Date <!(date))', ], 

चर के लिए, आप एक डिफ़ॉल्ट मान सेट कर सकते हैं, इसका उपयोग तब किया जाएगा जब अन्यथा उपयोग के स्थान पर चर को परिभाषित नहीं किया जाता है। डिफ़ॉल्ट मान सेट करने के लिए सिंटैक्स बहुत सहज नहीं है:

 { 'variables': { 'component_type%': 'shared_library', # <-  %     #     } #... } 

बाहरी निर्माण प्रणाली में परिभाषित चर को संदर्भित करना भी संभव है। make के make आप $ साइन (उदाहरण के लिए, $(INCLUDES) ) का उपयोग कर सकते हैं। दुर्भाग्य से, इस तरह के चर का उपयोग करने से विधानसभा कम पोर्टेबल हो जाती है।

स्थिति

conditions अनुभाग आपको कॉन्फ़िगरेशन के कुछ हिस्सों को घोषित करने की अनुमति देता है जो कि मॉड्यूल के बाह्य कारकों पर निर्भर करता है। उदाहरण के लिए, लक्ष्य ऑपरेटिंग सिस्टम पर या असेंबली (स्टैटिकली या डायनेमिकली लिंक्ड लाइब्रेरी) के वांछित प्रकार पर निर्भर करते हुए, आपको संकलन कोड बदलने या स्रोत कोड के साथ फ़ाइलों को जोड़ने / बाहर करने की आवश्यकता है।

यदि खंड की शर्त पूरी हो जाती है, तो इसकी घोषणाओं को उस उद्देश्य की घोषणाओं के साथ जोड़ा जाएगा, जिसमें स्थिति को परिभाषित किया गया है (या यदि target_conditions खंड में स्थिति घोषित की गई है तो सभी लक्ष्यों की घोषणाओं के साथ)।

एक सरल उदाहरण:

 { 'target_name': 'mylib', 'type': 'static_library', # ... 'conditions': [ ['OS=="linux"', { 'sources': ['linux_extra.cc'], # <-    'defines': ['UNIX=1'], # <-   UNIX   1 }], ], } 

शर्तों को __builtin__ डिक्शनरी के साथ eval() फ़ंक्शन का उपयोग करके पायथन इंटरप्रेटर द्वारा गणना की जाती है, इसलिए, वे बूलियन अभिव्यक्तियों के मूल्यांकन के लिए पायथन में स्वीकार किए गए वाक्यविन्यास का पालन करते हैं। उदाहरण के लिए, कई शर्तों को और or ऑपरेटरों के साथ जोड़ा जा सकता है। विकी पर पूर्वनिर्धारित चर और अधिक विस्तृत उदाहरणों की एक सूची पाई जा सकती है।

फाइलें शामिल करें

बड़ी परियोजनाओं में, ऐसी स्थिति संभव है कि प्रत्येक GYP फ़ाइल में घोषणाओं के हिस्से को फिर से लिखना होगा। #include निर्देश के समान फ़ाइल समावेश तंत्र का उपयोग करके इससे बचा जा सकता है। GYP में, इस तरह के तंत्र को शीर्ष-स्तरीय सूची के रूप में लागू किया जाता है:

 { 'includes': ['common.gypi', 'other.gypi'], # ... } 

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

डीबग और रिलीज़ : कॉन्फ़िगरेशन बनाएँ

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

निम्नलिखित पंक्तियों को हमारे gtest.gyp में जोड़ें :

 { 'target_defaults': { 'configurations': { 'Release': { 'conditions': [ ['OS=="linux"', { 'cflags': ['-O2'], #   }], ], }, 'Debug': { 'conditions': [ ['OS=="linux"', { 'cflags': ['-g', '-O0'], #  ,  }], #    ], }, }, }, 'targets': [ # ... ], } 

इस तथ्य पर ध्यान दें कि configurations अनुभाग को target_defaults अनुभाग में नेस्ट किया जाना चाहिए। यदि आप इसके बारे में भूल जाते हैं, तो त्रुटि संदेश, सबसे अधिक संभावना है, पालन नहीं करेगा, लेकिन कॉन्फ़िगरेशन काम नहीं करेगा।

make साथ निर्माण करते समय कॉन्फ़िगरेशन को निर्दिष्ट करने के make , बस BUILDTYPE पैरामीटर को परिभाषित करें। डिबगिंग के लिए, बिल्ड सिस्टम द्वारा निष्पादित वास्तविक कमांड को देखने के लिए अक्सर उपयोगी होता है। इसके लिए V (क्रिया) ध्वज जिम्मेदार है:

 make BUILDTYPE=Release V=1 

बेशक, आप मनमाने ढंग से सेटिंग्स के साथ मनमाने ढंग से संख्या को परिभाषित कर सकते हैं।

अब पुस्तकालय कई अन्य परियोजनाओं में उपयोग के लिए महान है, आपको बस इसे पदानुक्रमित परियोजना के विनिर्देश से संदर्भित करने की आवश्यकता है। शेष बोरिंग का काम जीवाईपी द्वारा किया जाएगा। मुझे लगता है कि इस रचना को और अधिक विस्तार से माना जाना चाहिए, क्योंकि यह अभ्यास में बहुत महत्वपूर्ण है।

हम कई मॉड्यूल एकत्र करते हैं

स्वतंत्र मॉड्यूल से एक परियोजना को इकट्ठा करने की सुविधा मुख्य गुणों में से एक है जो एक अच्छी परियोजना प्रबंधन प्रणाली होनी चाहिए, और इस संबंध में GYP उत्कृष्ट है।

दूसरे मॉड्यूल के रूप में, मैंने यह जांचने के लिए कई फ़ंक्शन चुने कि क्या इनपुट स्ट्रिंग सुंदर कोड बुक के पहले अध्याय में वर्णित सरलीकृत नियमित अभिव्यक्तियों से मेल खाती है (ISBN-10: 0596510047) (इस अध्याय का एक ऑनलाइन संस्करण भी उपलब्ध है)।

स्रोत कोड और कॉन्फ़िगरेशन वाला रिपॉजिटरी GitHub पर स्थित है ।

examples निर्देशिका में दो उपनिर्देशिकाएँ हैं: gtest-1.6 (ऊपर चर्चा की गई इकाई परीक्षण लिखने की इकाई) और mini-regex - हमारी माइक्रो-लाइब्रेरी जिसे स्वतंत्र विकास और परीक्षण की आवश्यकता है। यहाँ libminiregex.a लाइब्रेरी के निर्माण के लिए एक GYP फ़ाइल है, जो gtest घटक पर निर्भर करती है:

 { 'includes': ['../conf.gypi'], # <-   'targets': [ { 'target_name': 'miniregex', 'type': 'static_library', 'include_dirs': ['include'], 'sources': [ 'include/miniregex.hpp', # <-  'src/miniregex.cpp', # <-  ], 'direct_dependent_settings': { 'include_dirs': ['include'], }, }, { 'target_name': 'miniregex_test', 'type': 'executable', # <-   'dependencies': [ '../gtest-1.6/gtest.gyp:gtest', # <-      '../gtest-1.6/gtest.gyp:gtest_main', #   libminiregex,   'miniregex', ], 'sources': [ 'src/test/test_miniregex.cpp', # <-    ], }, ], } 

अलग-अलग स्पष्टीकरण अन्य GYP फ़ाइलों में घोषित निर्भरता को निर्दिष्ट करने के लिए सिंटैक्स के योग्य है। इस तरह की निर्भरता को इंगित करने के लिए, यह GYP फ़ाइल के लिए पथ को इंगित करने और लक्ष्य नाम (या तारांकन चिह्न, जिसका अर्थ है फ़ाइल के सभी लक्ष्यों पर निर्भरता) को एक कोलन के माध्यम से निर्दिष्ट करने के लिए पर्याप्त है।

नोट : यह याद रखना बहुत महत्वपूर्ण है कि जब कई मॉड्यूल से मिलकर एक परियोजना को इकट्ठा किया जाता है, तो सभी मॉड्यूल को उपयुक्त कॉन्फ़िगरेशन ( Debug , Release , आदि) निर्धारित करना होगा। आवश्यक कॉन्फ़िगरेशन की अनुपस्थिति में, प्रोजेक्ट फ़ाइलों को संकलित करने के चरण में कोई चेतावनी प्रदर्शित नहीं की जाएगी, लेकिन जब निर्माण की कोशिश की जाती है, तो सबसे अधिक संभावना है, रहस्यमय त्रुटि संदेश प्रदर्शित किए जाएंगे।

प्रदर्शन उद्देश्यों के लिए, दोनों मॉड्यूल एक सामान्य conf.gypi फ़ाइल साझा करते हैं जिसमें कॉन्फ़िगरेशन परिभाषाएं होती हैं। इससे समझ में आता है कि क्या मॉड्यूल को उसी रिपॉजिटरी में संग्रहीत किया जाना है। फिर भी, मुझे पुन: उपयोग के लिए उपयुक्त स्वतंत्र मॉड्यूल को स्थानांतरित करने के लिए यह एक अच्छा विचार है (हमारे दो पुस्तकालय इसके लिए अच्छे लगते हैं), अलग-अलग रिपॉजिटरी में और उन्हें बाहरी लिंक तंत्र (जैसे svn:externals या git submodule ) के माध्यम से उपयोग करते हैं।

mini-regex मॉड्यूल का निर्माण करने के लिए, आपको examples निर्देशिका में जाने और परिचित कमांड को निष्पादित करने की आवश्यकता है:

 gyp --depth=. mini-regex/miniregex.gyp make 

सबसे पहले, gtest मॉड्यूल पुस्तकालयों को इकट्ठा किया जाएगा, फिर libminiregex.a लाइब्रेरी, फिर libminiregex.a निष्पादन योग्य फ़ाइल, जो बाहर / डिबग निर्देशिका में पाई जा सकती है, पहले से ही संकलित की जाएगी। यदि सब कुछ सही ढंग से किया जाता है, जब आप इस निष्पादन योग्य फ़ाइल को कंसोल पर चलाते हैं, तो एक सकारात्मक हरा-भरा GTest आउटपुट दिखाई देना चाहिए।

अब तक हमने केवल दो मॉड्यूल कनेक्ट किए हैं, लेकिन दृष्टिकोण पूरी तरह से मापता है, जिससे आप बिना किसी समस्या के मॉड्यूल के पदानुक्रमों की रचना कर सकते हैं, जिससे आपकी प्रत्येक GYP फ़ाइल में मॉड्यूल के प्रत्येक असेंबली विवरण को समझाया जा सके, और प्रत्येक मॉड्यूल दूसरों से स्वतंत्र रूप से इकट्ठा किया जा सके। इस वास्तुकला का एक महत्वपूर्ण उदाहरण क्रोमियम प्रोजेक्ट है।

कार्य और नियम

अक्सर, विधानसभा के दौरान, आपको कुछ कार्रवाई या गैर-मानक रूपांतरण करने की आवश्यकता होती है।

क्रियाएँ अनुभाग का उपयोग एक बार की actions को परिभाषित करने के लिए किया जाता है, rules अनुभाग का उपयोग परिवर्तनों को परिभाषित करने के लिए किया जाता है। नियमों का उपयोग परिवर्तन श्रृंखला बनाने के लिए किया जा सकता है, इसी तरह यह जीएनयू बनाने में लागू किया जाता है। नियमों को एक्शन पैटर्न के रूप में भी सोचा जा सकता है।

जीटीएस्ट मॉड्यूल के पुस्तकालयों और हेडर फ़ाइलों को स्थापित करने के लिए कार्रवाई के कार्यान्वयन के रूप में:

 { 'target_name': 'install', 'type': 'none', 'dependencies': ['gtest', 'gtest_main'], # <-    #   'actions': [ { 'inputs': [], 'outputs': ['$(LIBRARIES)/libgtest.a', '$(LIBRARIES)/libgtest_main.a'], 'action_name': 'copy_libs', 'action': ['cp', '<(PRODUCT_DIR)/libgtest.a', '<(PRODUCT_DIR)/libgtest_main.a', '$(LIBRARIES)'], 'message': 'Copying libraries', }, { 'inputs': [], 'outputs': ['$(INCLUDES)/gtest', '$(INCLUDES)/gtest/internal'], 'action_name': 'copy_headers', 'action': ['cp', '-R', 'include/gtest', '$(INCLUDES)'], 'message': 'Copying header files', } ], } 

बाहरी चर का उपयोग यहां किया जाता है, यह निहित है कि make को पर्यावरण या कमांड लाइन तर्कों के माध्यम से LIBRARIES और LIBRARIES प्राप्त होंगे:

 gyp --depth=. gtest.gyp #        sudo make install INCLUDES=/usr/include LIBRARIES=/lib64 

मेरे प्रोजेक्ट में, मैं RPM पैकेज बनाने के लिए एक समान तकनीक का उपयोग करता हूं।

एक नियम का एक उदाहरण rst2html नियम है, जिसका उपयोग मैं RST प्रारूप से HTML प्रारूप में प्रलेखन संकलित करने के लिए करता हूं:

 { 'target_name': 'docs', 'type': 'none', 'sources': [ 'doc/Build.rst', 'doc/Dictionary.rst', 'doc/README.rst', ], 'rules': [{ 'rule_name': 'rst2html', 'extension': 'rst', 'inputs': ['doc/css/code.css'], 'action': ['rst2html.py', '--stylesheet-path=doc/css/code.css', '--embed-stylesheet', '<(RULE_INPUT_PATH)', '<(PRODUCT_DIR)/Doc/<(RULE_INPUT_ROOT).html'], 'outputs': ['<(PRODUCT_DIR)/Doc/<(RULE_INPUT_ROOT).html'], 'message': 'Compiling RST document <(RULE_INPUT_PATH)' \ 'to HTML <(PRODUCT_DIR)/Doc/<(RULE_INPUT_ROOT).html', }], }, 

extension संपत्ति नियम के अंतर्गत आने वाली फ़ाइलों के विस्तार को निर्दिष्ट करती है, और inputs सूची उन फ़ाइलों को परिभाषित करती है जो अतिरिक्त निर्भरता हैं (यानी, यदि वे बदलते हैं, तो आपको नियम को फिर से लागू करने की आवश्यकता है)। चर RULE_INPUT_PATH इनपुट एक्शन फ़ाइल RULE_INPUT_ROOT के निरपेक्ष पथ के लिए बाध्य है - इनपुट फ़ाइल के पथ के आधार पर (यानी बिना विस्तार के)। मुझे लगता है कि बाकी लोगों को सवालों का कारण नहीं बनना चाहिए।

जैसा कि आप उदाहरण से देख सकते हैं, वाक्यविन्यास काफी सरल है, लेकिन कॉम्पैक्टनेस वांछित होने के लिए बहुत कुछ छोड़ देता है। तुलना के लिए, इस लक्ष्य को निम्नलिखित make कोड के साथ महसूस किया जा सकता है (बेशक, यह वह कोड नहीं है जो GYP उत्पन्न करता है):

 BUILDTYPE ?= Debug PRODUCT_DIR ?= out/$(BUILDTYPE) HTML_OUT := $(PRODUCT_DIR)/Doc RST_DOCS := doc/Build.rst doc/Dictionary.rst doc/README.rst HTML_DOCS := $(patsubst doc/%.rst,$(HTML_OUT)/%.html,$(RST_DOCS)) .PHONY: docs docs: $(HTML_DOCS) # ,   $(HTML_OUT)/%.html: doc/%.rst doc/css/code.css mkdir -p $(HTML_OUT) rst2html.py --stylesheet-path=../doc/css/code.css \ --embed-stylesheet $< $@ 

यह देखा जा सकता है कि GYP नियमों को परिभाषित करने के make सिंटैक्स make सिंटैक्स की तुलना में कुछ अधिक है, लेकिन शायद GNU make में अनुभवी लोगों के लिए अधिक पठनीय है।

वे आमतौर पर क्रॉस-प्लेटफ़ॉर्म टूल का उपयोग करके क्रियाओं और परिवर्तनों को लागू करने का प्रयास करते हैं, आमतौर पर पायथन स्क्रिप्ट।

क्रियाओं और पूर्वनिर्धारित चरों की घोषणा के प्रारूप का विवरण आधिकारिक विकि ( कार्य , नियम ) पर पाया जा सकता है।

आउट सोर्स सोर्स की

जिन पाठकों ने लिनक्स के तहत GYP को चलाने का प्रयास किया, उन्होंने देखा कि वांछित निर्देशिकाओं के अलावा बड़े पैमाने पर बाहर की निर्देशिका में तह किए गए, GYP कई मेकफाइल्स बनाता है (प्रत्येक लक्ष्य के लिए एक या दो + एक मुख्य मेकफाइल) जो निर्देशिका के साथ निर्देशिका को रोकते हैं कोड। मैं चाहूंगा कि ये मध्यवर्ती फाइलें बाहर की निर्देशिका में भी बनाई जाएं। इस समस्या के समाधान का एक उदाहरण V8 स्रोत कोड में पाया जा सकता है। यह --generator-output विकल्प सेट करने और विकल्प द्वारा निर्दिष्ट निर्देशिका से रन make लिए पर्याप्त है:

 gyp --depth=. --generator-output=./out gtest.gyp make -C out 

निष्कर्ष

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

परियोजना के आकर्षण और परिपक्वता के बावजूद, इस पर प्रलेखन काफी छोटा है। अधिकांश व्यावहारिक ज्ञान क्रोमियम और वी 8 के स्रोत कोड से निकाला जाना है। पहले से ही उल्लिखित विकी में GYP फ़ाइलों के प्रारूप का एक विस्तृत विवरण है, लेकिन दुर्भाग्य से उपयोग के पर्याप्त उदाहरण नहीं हैं। मुझे उम्मीद है कि यह लेख बेहतर के लिए एक फर्क पड़ेगा।

साधन

• प्रोजेक्ट पेज
• एक सी लाइब्रेरी को जिप करने के लिए परिवर्तित करना
• क्रोमियम स्रोत कोड
• V8 स्रोत कोड