Ninja: सापेक्ष सबनिंजा पथ हल नहीं होते

सभी पथ निर्माण निर्देशिका से संबंधित हैं, न कि सबनिंजा लाइन वाली फ़ाइल के लिए।

हालांकि इसका कोई मतलब नहीं है। इसका मतलब है कि जेनरेटर को फाइलों के लिए एक उपसर्ग को प्रीपेन्ड करने के लिए _all_ लागू करना होगा, जिसका अर्थ है कि कार्यशील निर्देशिका कमांड को चलाना (जो जेनरेटर/कमांड कैसे चलता है, इस पर निर्भर करता है कि बिल्ड कॉन्फ़िगरेशन का मूल इरादा बदल सकता है)।

तो फिर, subninja बनाम include के विपरीत उपयोग के मामले क्या हैं?

बिल्ड फ़ाइल के सापेक्ष पथ के साथ एक सबनिंजा उस निर्भरता में उपयोगी होगा जो अपनी निर्देशिका में चलाने के लिए कॉन्फ़िगर किए गए हैं, अपने पथ को संशोधित किए बिना ऐसा कर सकते हैं, लेकिन फिर भी माता-पिता निंजा कॉन्फ़िगरेशन के निर्भरता ग्राफ में योगदान दे सकते हैं।

include कार्यक्षमता को संशोधित नहीं किया जाएगा, और वास्तव में कार्य करेगा कि कैसे सबनिंजा तथ्य नियम नामों के अलावा अन्य कार्य करता है अब एक संयुक्त नामस्थान (# 921 के अनुसार) में होगा। वर्तमान में, subninja और include स्कोपिंग चर और नियम नामों के अलावा अनिवार्य रूप से वही चीज़ प्राप्त करते हैं ...

विचार यह है कि जनरेटर सभी .ninja फ़ाइलें उत्पन्न करता है, इसलिए वे बिल्ड निर्देशिका के सापेक्ष पथ लिख सकते हैं। विभिन्न जनरेटर द्वारा उत्पन्न निंजा फ़ाइलों को संयोजित करना एक दिलचस्प विचार है (ऐसा लगता है कि आप यही करना चाहते हैं?), लेकिन यह ऐसा कुछ नहीं है जो इस समय समर्थित है।

सही है, subninja और include के बीच का अंतर यह है कि पूर्व एक दायरा जोड़ता है और बाद वाला नहीं। इसके लिए उपयोग का मामला यह है कि टॉपलेवल निंजा सामान्य बिल्ड नियमों को परिभाषित कर सकता है जैसे कि cc जो संदर्भ चर जैसे cflags , और प्रत्येक सबनिंजा उस लक्ष्य के लिए उपयुक्त के लिए cflags सेट कर सकता है, और वहां वहां एकतरफा कार्रवाई हो सकती है। एक उदाहरण देखने के लिए, आप इस पैटर्न का उपयोग करने वाले /tmp/foo पर .ninja फ़ाइलों का एक गुच्छा लिखने के लिए python Misc/write_fake_manifests.py /tmp/foo` चला सकते हैं।

यह समझ में आता है, हालांकि मुझे अभी भी बहुत अधिक लाभ नहीं दिख रहा है (दायरे के अलावा)।

विभिन्न जनरेटर द्वारा उत्पन्न निंजा फ़ाइलों को संयोजित करना एक दिलचस्प विचार है (ऐसा लगता है कि आप यही करना चाहते हैं?)

बिल्कुल। निंजा को मेरे जनरेटर के लिए एक सबमॉड्यूल के रूप में शामिल करने में सक्षम होने के नाते, और फिर एक और सीएमके प्रोजेक्ट (जो निंजा बिल्ड फाइलों को आउटपुट करने के लिए कॉन्फ़िगर किया गया है), और फिर दोनों के लिए निंजा कॉन्फिग फाइलों को उत्पन्न करना और उन्हें subninja s के रूप में शामिल करना _my_ प्रोजेक्ट की build.ninja फ़ाइल को बनाने में सक्षम होने के लिए जैसे कि वे अपने दम पर थे, लेकिन फिर भी मेरे प्रोजेक्ट को उनके आउटपुट (और इस प्रकार उनके निर्भरता ग्राफ़) का उपयोग करने की अनुमति देते हैं ताकि एक ही बार में पूरी परियोजना का निर्माण किया जा सके। .

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

मुझे व्यक्तिगत रूप से लगता है कि यह subninja को पूरी तरह से अधिक उपयोगी बना देगा, हालांकि मैं इसे संभावित रूप से तोड़ने वाला परिवर्तन देख सकता था। हालांकि, मुझे इसके आस-पास कोई रास्ता नहीं दिखता है जब तक कि 1) मैं निर्भरताओं की build.ninja फाइलों को पैच के साथ संशोधित करता हूं या 2) निर्भरताओं की निर्भरता ग्राफ का उपयोग करने की क्षमता का त्याग करता हूं।

विचार?

कैसा रहेगा:

subninja path/to/build.ninja relative path/to

और अनुपस्थित relative डिफ़ॉल्ट रूप से ./ है। यह इसे गैर-ब्रेकिंग बना देगा लेकिन फिर भी यदि जनरेटर की इच्छा हो तो कार्यक्षमता दें।

या, अन्य निन्जा निर्माणों के चरणों का अनुसरण करते हुए, हो सकता है

subninja path/to/build.ninja
  relative = path/to

मान लीजिए कि आपके पास .../foo पर एक प्रोजेक्ट है और इसमें एक उपनिर्देशिका बार है, और निंजा के पास आपके द्वारा सुझाए गए सापेक्ष-पथ तर्क थे।

यदि आपका बिल्ड सिस्टम सभी बिल्ड आउटपुट को /foo/obj पर लिखना चाहता है, तो /foo/bar में एक सबनिजा जो निर्देशिका-सापेक्ष पथों का उपयोग करता है, को इसके आउटपुट को ../obj/bar में लिखने के लिए जानना होगा, क्योंकि यह पथ है उस उपनिर्देशिका से फ़ाइल। तो जो कुछ भी आपकी बिल्ड.निंजा फाइलों को उत्पन्न कर रहा है, उसे पहले से ही वैश्विक पथ पदानुक्रम के बारे में पता होना चाहिए, इस मामले में सभी पथों को सापेक्ष बनाना प्रभावी रूप से वही समस्या है जैसे बार/निर्देशिका में पथों के लिए बार/प्रस्तुत करना।

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

मुझे यकीन नहीं कि मैं समझा हूँ। Subninjas, उपयोग-मामले में मैंने विशेष रूप से वर्णित किया है, आमतौर पर माता-पिता निंजा की संरचना के बारे में नहीं जानते (कम से कम, जानने की जरूरत नहीं है)। मुझे यकीन है कि वहां कोई ऐसा मामला ढूंढ सकता है जहां वे करते हैं।

जिस समस्या का मैं अभी सामना कर रहा हूं वह निर्भरता (तृतीय पक्ष पुस्तकालय, आदि) है जो मेरे जनरेटर का उपयोग नहीं करता है (जो उनमें से 100% है) वर्तमान में बूटस्ट्रैपर का उपयोग करके बनाया जाना चाहिए, और हर बार बूटस्ट्रैप किया जाना चाहिए अपडेट किए गए या बदले गए, आदि। जिन जेनरेटरों के साथ मैं काम करता हूं उनमें निंजा कॉन्फ़िगरेशन के आउटपुट के विकल्प होते हैं, लेकिन वे सभी अकेले उस निर्देशिका के लिए कॉन्फ़िगर किए जाते हैं (यानी उस निर्देशिका के सापेक्ष)।

उनके कॉन्फ़िगरेशन और ग्राफ़ का उपयोग करके चयनात्मक पुनर्निर्माण करने में सक्षम होना बहुत बड़ा होगा। वर्तमान में, मैं इस तथ्य के कारण ऐसा नहीं कर सकता subninja निर्माण निर्देशिका के सापेक्ष पथ मानता है।

इवान: जिस तरह से मैंने इसे समझा है कि आप इस तरह एक पेड़ बनाएंगे:

  subbuild1
  subbuild2

और चूंकि जेनरेटर आमतौर पर बिल्ड डीआईआर को मनमानी जगहों पर रखने का समर्थन करते हैं, सबबिल्ड 1 में प्रोजेक्ट 1 और सबबिल्ड 2 में प्रोजेक्ट 2 को काम करना चाहिए। फिर बिल्डडिर में एक टॉपलेवल निंजा फ़ाइल है जिसे Qix- सबप्रोजेक्ट्स के निर्माण के लिए ड्राइव करना चाहता है।

असंबंधित: इस relative सुविधा को cwd को इसके तर्क में भी बदलना होगा यदि कोई नियम वर्तमान निर्देशिका पर उनके निर्माण dir के बराबर होने पर निर्भर करता है (कहते हैं, यदि कोई नियम निर्मित कलाकृतियों या कुछ को स्ट्रिप्स करता है)।