विपक्ष - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

विपक्ष - एक सॉफ्टवेयर निर्माण प्रणाली

वर्णन

संस्करण 2.2.0 के लिए एक मार्गदर्शिका और संदर्भ

कॉपीराइट (सी) 1996-2000 फ्री सॉफ्टवेयर फाउंडेशन, इंक।

यह कार्यक्रम मुफ्त सॉफ्टवेयर है; आप इसे पुनर्वितरित कर सकते हैं और/या इसे की शर्तों के तहत संशोधित कर सकते हैं
फ्री सॉफ्टवेयर फाउंडेशन द्वारा प्रकाशित जीएनयू जनरल पब्लिक लाइसेंस; दोनों में से एक
लाइसेंस का संस्करण 2, या (आपके विकल्प पर) कोई बाद का संस्करण।

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

आपको इस कार्यक्रम के साथ GNU जनरल पब्लिक लाइसेंस की एक प्रति प्राप्त होनी चाहिए;
प्रतिलिपि फ़ाइल देखें। यदि नहीं, तो फ्री सॉफ्टवेयर फाउंडेशन, इंक., 59 टेम्पल को लिखें
स्थान - सुइट 330, बोस्टन, एमए 02111-1307, यूएसए।

परिचय

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

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

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

क्यों दोष? क्यों नहीं बनाना?

विपक्ष एक है बनाना प्रतिस्थापन। निम्नलिखित पैराग्राफ में, हम इनमें से कुछ को देखते हैं
मेक की अवांछनीय विशेषताएं - और मेक पर आधारित विशिष्ट निर्माण वातावरण
विपक्ष के विकास को प्रेरित किया।

बनाएँ जटिलता

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

बनाएँ reproducibility

सभी निर्माणों का अभिशाप हमेशा निर्भरता का सही प्रबंधन रहा है। सबसे अधिक बार, ए
एक ही निर्देशिका के भीतर निर्भरता का उचित कार्य करने का प्रयास किया गया है, लेकिन नहीं
निर्देशिकाओं के बीच कार्य करने का गंभीर प्रयास किया गया है। निर्भरताएँ होने पर भी
सही ढंग से काम करते हुए, यह निर्धारित करने के लिए एक साधारण टाइम स्टैम्प तुलना पर भरोसा करें
एक फ़ाइल अपने आश्रितों के संबंध में पुरानी हो गई है, सामान्य तौर पर, इसके लिए पर्याप्त नहीं है
यह निर्धारित करना कि किसी फ़ाइल को कब पुनः प्राप्त किया जाना चाहिए। उदाहरण के लिए, यदि कोई बाहरी लाइब्रेरी है
फिर से बनाया गया और फिर अपनी जगह पर ``स्नैप'' किया गया, इसकी नई बनाई गई फ़ाइलों पर टाइमस्टैम्प हो सकते हैं
यह पिछले स्थानीय निर्माण से पहले का होगा, क्योंकि इसे दृश्यमान होने से पहले ही बनाया गया था।

प्रकार बनाता है

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

डेटा संग्रह स्थान

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

रखना it सरल

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

पर्ल लिपियों

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

नमस्ते, विश्व!

निम्नलिखित चर्चा को आधार बनाने के लिए, यहां बताया गया है कि आप इसका निर्माण कैसे कर सकते हैं नमस्ते, विश्व! C
विपक्ष के साथ आवेदन:

$env = नया विपक्ष();
प्रोग्राम $env 'हैलो', 'हैलो.c';

यदि आप इस स्क्रिप्ट को किसी निर्देशिका में स्थापित करते हैं, तो स्क्रिप्ट का नामकरण करें के निर्माण के, और बनाएँ
नमस्ते सी स्रोत फ़ाइल को उसी निर्देशिका में रखें, फिर आप इसे बनाने के लिए `cons hello' टाइप कर सकते हैं
आवेदन:

% विपक्ष नमस्ते
सीसी -सी हैलो.सी -ओ हैलो.ओ
सीसी -ओ हेलो हेलो.ओ

निर्माण वातावरण

विपक्ष का एक प्रमुख सरलीकरण एक का विचार है निर्माण वातावरण. एक निर्माण
पर्यावरण एक है वस्तु कुंजी/मान जोड़े के एक सेट और के एक सेट द्वारा विशेषता तरीकों.
विपक्ष को यह बताने के लिए कि कुछ कैसे बनाया जाए, आप एक के माध्यम से उचित विधि का आह्वान करते हैं
उपयुक्त निर्माण वातावरण. निम्नलिखित उदाहरण पर विचार करें:

$env = नया विपक्ष(
सीसी => 'जीसीसी',
LIBS => 'libworld.a'
);

प्रोग्राम $env 'हैलो', 'हैलो.c';

इस मामले में, डिफ़ॉल्ट निर्माण वातावरण का उपयोग करने के बजाय, जैसा कि हमारे पास है
`सीसी' के मान को ओवरराइड कर दिया गया ताकि इसके बजाय जीएनयू सी कंपाइलर समकक्ष का उपयोग किया जा सके। तब से
का यह संस्करण नमस्ते, विश्व! एक पुस्तकालय की आवश्यकता है, libworld.a, हमने निर्दिष्ट किया है कि कोई भी
इस वातावरण में जुड़े प्रोग्राम को उस लाइब्रेरी से जोड़ा जाना चाहिए। यदि पुस्तकालय
पहले से मौजूद है, ठीक है और अच्छा है, लेकिन यदि नहीं, तो हमें यह कथन भी शामिल करना होगा:

लाइब्रेरी $env 'libworld', 'world.c';

अब यदि आप `cons hello' टाइप करते हैं, तो प्रोग्राम लिंक होने से पहले ही लाइब्रेरी बन जाएगी, और,
बेशक, दोनों मॉड्यूल को संकलित करने के लिए `gcc' का उपयोग किया जाएगा:

% विपक्ष नमस्ते
जीसीसी -सी हैलो.सी -ओ हैलो.ओ
जीसीसी -सी वर्ल्ड.सी -ओ वर्ल्ड.ओ
एआर आर लिबवर्ल्ड.ए वर्ल्ड.ओ
ar: libworld.a बनाना
ranlib libworld.a
जीसीसी -ओ हैलो hello.o libworld.a

स्वचालित और पूरा निर्भरता विश्लेषण

विपक्ष के साथ, निर्भरताएँ स्वचालित रूप से नियंत्रित की जाती हैं। पिछले उदाहरण को जारी रखते हुए, ध्यान दें
कि जब हम संशोधित करते हैं विश्व.सी, विश्व.ओ पुनः संकलित किया गया है, libworld.a पुनः निर्मित, और नमस्ते
पुनः जोड़ा गया:

% vi विश्व.सी
[संपादित करें]
% विपक्ष नमस्ते
जीसीसी -सी वर्ल्ड.सी -ओ वर्ल्ड.ओ
एआर आर लिबवर्ल्ड.ए वर्ल्ड.ओ
ar: libworld.a बनाना
ranlib libworld.a
जीसीसी -ओ हैलो hello.o libworld.a

यह अपेक्षाकृत सरल उदाहरण है: विपक्ष ``जानता है'' विश्व.ओ पर निर्भर करता है विश्व.सी, क्योंकि
निर्भरता स्पष्ट रूप से 'लाइब्रेरी' विधि द्वारा स्थापित की गई है। ये भी जानता है libworld.a
पर निर्भर करता है विश्व.ओ और है कि नमस्ते पर निर्भर करता है libworld.a, सभी समान कारणों से।

अब यह पता चला है नमस्ते सी इंटरफ़ेस परिभाषा फ़ाइल भी शामिल है, विश्व.एच:

% इमैक वर्ल्ड.एच
[संपादित करें]
% विपक्ष नमस्ते
जीसीसी -सी हैलो.सी -ओ हैलो.ओ
जीसीसी -ओ हैलो hello.o libworld.a

विपक्ष को यह कैसे पता नमस्ते सी शामिल विश्व.एच, और वह हेलो.ओ इसलिए होना चाहिए
पुनः संकलित? अभी के लिए, यह कहना पर्याप्त होगा कि विचार करते समय कि क्या या नहीं हेलो.ओ ऊपर है-
आज तक, विपक्ष अपनी निर्भरता के लिए एक स्कैनर का आह्वान करता है, नमस्ते सी. यह स्कैनर गणना करता है
फ़ाइलें शामिल हैं नमस्ते सी उनसे परे, अन्य निर्भरताओं की एक सूची तैयार करना
विपक्ष स्क्रिप्ट द्वारा स्पष्ट किया गया। यह प्रक्रिया पुनरावर्ती है: इसमें शामिल कोई भी फ़ाइल
सम्मिलित फ़ाइलें भी स्कैन की जाएंगी.

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

स्वचालित वैश्विक निर्माण अनुक्रमण

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

इमारत बड़ा पेड़--अभी भी केवल as सरल

A पदक्रम of निर्माण लिपियों

विपक्ष में एक बड़ा निर्माण, का एक पदानुक्रम बनाकर आयोजित किया जाता है निर्माण लिपियों. शीर्ष पर
पेड़ की एक लिपि है जिसे कहा जाता है के निर्माण के. परंपरा के अनुसार शेष स्क्रिप्टें प्रत्येक हैं
बुलाया भरती होनेवाला. ये स्क्रिप्ट बहुत ही सरलता से, 'बिल्ड' द्वारा एक साथ जुड़ी हुई हैं,
`निर्यात', और `आयात' आदेश।

RSI बनाएँ आदेश

`बिल्ड' कमांड एक सूची लेता है भरती होनेवाला फ़ाइल नाम, और उनके लिए व्यवस्था करता है
निर्माण में शामिल है। उदाहरण के लिए:

क्यूडब्ल्यू बनाएं(
ड्राइवर/डिस्प्ले/कॉनस्क्रिप्ट
ड्राइवर/माउस/कॉनस्क्रिप्ट
पार्सर/कॉनस्क्रिप्ट
उपयोगिताएँ/कॉन्स्क्रिप्ट
);

यह बिल्ड स्क्रिप्ट का एक सरल दो-स्तरीय पदानुक्रम है: सभी सहायक भरती होनेवाला फ़ाइलों
शीर्ष स्तर पर उल्लिखित हैं के निर्माण के फ़ाइल। ध्यान दें कि सभी निर्देशिकाएँ पेड़ में नहीं हैं
उनके साथ आवश्यक रूप से बिल्ड स्क्रिप्ट संबद्ध होनी चाहिए।

इसे बहुस्तरीय स्क्रिप्ट के रूप में भी लिखा जा सकता है। उदाहरण के लिए, के निर्माण के फ़ाइल हो सकती है
यह आदेश शामिल करें:

क्यूडब्ल्यू बनाएं(
पार्सर/कॉनस्क्रिप्ट
ड्राइवर/सिपाही
उपयोगिताएँ/कॉन्स्क्रिप्ट
);

और भरती होनेवाला में दायर ड्राइवरों निर्देशिका में यह शामिल हो सकता है:

क्यूडब्ल्यू बनाएं(
डिस्प्ले/कॉन्स्क्रिप्ट
माउस/कंसक्रिप्ट
);

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

डिफ़ॉल्ट रूप से, विपक्ष अपनी कार्यशील निर्देशिका को a वाली निर्देशिका में नहीं बदलता है
सहायक भरती होनेवाला फ़ाइल इसमें शामिल है। इस व्यवहार को बिल्ड बाय के लिए सक्षम किया जा सकता है
शीर्ष स्तर पर निर्दिष्ट करना के निर्माण के फ़ाइल:

कॉन्स्क्रिप्ट_चडीर 1;

सक्षम होने पर, विपक्ष सहायक में बदल जाएगा भरती होनेवाला फ़ाइल की निर्देशिका युक्त
उस फ़ाइल में पढ़ते समय, और फिर फ़ाइल को एक बार शीर्ष-स्तरीय निर्देशिका में वापस बदलें
संसाधित किया गया।

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

कॉन्स्क्रिप्ट_चडीर 0;

रिश्तेदार, शीर्ष-सापेक्ष, और पूर्ण पट्टिका नामों

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

का प्रयोग मॉड्यूल in निर्माण लिपियों

आप प्रत्येक में मॉड्यूल खींच सकते हैं भरती होनेवाला सामान्य पर्ल `उपयोग' या `आवश्यकता' का उपयोग करके फ़ाइल करें
बयान:

अंग्रेजी का उपयोग करो;
My::मॉड्यूल की आवश्यकता है;

प्रत्येक 'उपयोग' या 'आवश्यकता' केवल एक को प्रभावित करती है भरती होनेवाला वह फ़ाइल जिसमें यह दिखाई देता है. ए का उपयोग करने के लिए
एकाधिक में मॉड्यूल भरती होनेवाला फ़ाइलों में, आपको प्रत्येक में 'उपयोग' या 'आवश्यकता' कथन डालना होगा
जिसे मॉड्यूल की आवश्यकता है।

विस्तार of चर

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

चर स्पष्ट रूप से हो सकते हैं आयातित इसकी मूल लिपि की एक स्क्रिप्ट द्वारा। आयात करने के लिए ए
परिवर्तनशील, यह अवश्य रहा होगा निर्यात माता-पिता द्वारा और प्रारंभ किया गया (अन्यथा एक त्रुटि
घटेगा)।

RSI निर्यात आदेश

'निर्यात' कमांड का उपयोग निम्नलिखित उदाहरण में किया गया है:

$env = नया विपक्ष();
$INCLUDE = "#निर्यात/शामिल";
$LIB = "#export/lib";
निर्यात qw(env LIB शामिल करें);
क्यूडब्ल्यू बनाएं (उपयोग/कॉन्स्क्रिप्ट);

'निर्यात' सूची में उल्लिखित सरल चर के मान दूर हो जाएंगे
किसी भी बाद के `बिल्ड' कमांड द्वारा। 'एक्सपोर्ट' कमांड केवल पर्ल को एक्सपोर्ट करेगा अदिश
वेरिएबल, यानी वे वेरिएबल जिनका नाम `$' से शुरू होता है। अन्य चर, वस्तुएँ, आदि।
संदर्भ द्वारा निर्यात किया जा सकता है--लेकिन सभी स्क्रिप्ट एक ही ऑब्जेक्ट को संदर्भित करेंगी, और यह
ऑब्जेक्ट को सहायक स्क्रिप्ट और मूल द्वारा केवल पढ़ने योग्य माना जाना चाहिए
स्क्रिप्ट निर्यात करना. हालाँकि, निर्यातित स्केलर को एक नया मान निर्दिष्ट करना स्वीकार्य है
वेरिएबल--जो संदर्भित अंतर्निहित वेरिएबल को नहीं बदलेगा। यह क्रम, के लिए
उदाहरण, ठीक है:

$env = नया विपक्ष();
निर्यात qw(env LIB शामिल करें);
क्यूडब्ल्यू बनाएं (उपयोग/कॉन्स्क्रिप्ट);
$env = नया विपक्ष(CFLAGS => '-O');
बिल्ड क्यूडब्ल्यू (अन्य/कॉनस्क्रिप्ट);

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

RSI आयात आदेश

'एक्सपोर्ट' कमांड द्वारा निर्यात किए गए वेरिएबल्स को सहायक स्क्रिप्ट में आयात किया जा सकता है
'आयात' आदेश. सहायक स्क्रिप्ट हमेशा से सीधे वेरिएबल आयात करती है
श्रेष्ठ स्क्रिप्ट. इस उदाहरण पर विचार करें:

आयात qw(env शामिल);

यह केवल तभी कानूनी है जब मूल स्क्रिप्ट `$env' और `$INCLUDE' दोनों को निर्यात करती है। यह होना भी चाहिए
इनमें से प्रत्येक चर का मान दिया गया है। यह केवल सहायक स्क्रिप्ट के लिए ही ठीक है
निर्यातित चर का एक उपसमूह आयात करें (इस उदाहरण में, `$LIB', जिसे निर्यात किया गया था
पिछला उदाहरण आयातित नहीं है)।

सभी आयातित चर स्वचालित रूप से पुनः निर्यात किए जाते हैं, इसलिए अनुक्रम:

आयात qw (env शामिल);
क्यूडब्ल्यू बनाएं (नीचे-मी/कॉनस्क्रिप्ट);

सहायक फ़ाइल में `$env' और `$INCLUDE' दोनों की आपूर्ति करेगा। यदि केवल `$env' होना है
निर्यात किया गया है, तो निम्नलिखित पर्याप्त होगा:

आयात qw (env शामिल);
निर्यात क्यूडब्ल्यू (एनवी);
क्यूडब्ल्यू बनाएं (नीचे-मी/कॉनस्क्रिप्ट);

कहने की जरूरत नहीं है, 'बिल्ड' को लागू करने से पहले वेरिएबल को स्थानीय रूप से संशोधित किया जा सकता है
सहायक लिपि.

बनाएँ लिपि मूल्यांकन आदेश

बिल्ड स्क्रिप्ट के क्रम पर एकमात्र बाधा यह है कि बेहतर स्क्रिप्ट होती हैं
उनकी घटिया लिपियों से पहले मूल्यांकन किया गया। शीर्ष स्तर के निर्माण के उदाहरण के लिए, फ़ाइल है
पहले मूल्यांकन किया जाता है, उसके बाद किसी घटिया स्क्रिप्ट का। यह वह सब है जो आपको वास्तव में जानने की आवश्यकता है
मूल्यांकन आदेश के बारे में, क्योंकि आदेश आम तौर पर अप्रासंगिक है। निम्न पर विचार करें
`बिल्ड' कमांड:

क्यूडब्ल्यू बनाएं(
ड्राइवर/डिस्प्ले/कॉनस्क्रिप्ट
ड्राइवर/माउस/कॉनस्क्रिप्ट
पार्सर/कॉनस्क्रिप्ट
उपयोगिताएँ/कॉन्स्क्रिप्ट
);

हमने स्क्रिप्ट नामों को वर्णानुक्रम में रखना चुना है, केवल इसलिए क्योंकि यह सबसे अधिक है
रखरखाव के प्रयोजनों के लिए सुविधाजनक। ऑर्डर बदलने से कोई फर्क नहीं पड़ेगा
निर्माण।

A आदर्श एसटी बांटने फ़ाइलों

कुछ सरल सम्मेलनों

किसी भी जटिल सॉफ़्टवेयर सिस्टम में, बिल्ड उत्पादों को साझा करने के लिए एक विधि की आवश्यकता होती है
स्थापित। हम सम्मेलनों का एक सरल सेट प्रस्तावित करते हैं जिन्हें लागू करना मामूली है
विपक्ष, लेकिन बहुत प्रभावी.

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

इन निर्देशिकाओं को शीर्ष-स्तर द्वारा परिभाषित किया गया है के निर्माण के फ़ाइल। एक साधारण के निर्माण के के लिए दर्ज
a नमस्ते, विश्व! एकाधिक निर्देशिकाओं का उपयोग करके व्यवस्थित किया गया एप्लिकेशन इस तरह दिख सकता है:

# हेलो, वर्ल्ड के लिए फ़ाइल बनाएं!

# हमारे सभी साझा उत्पाद कहां रखे जाएं.
$निर्यात = '#निर्यात';

निर्यात qw(विपक्ष में लिब बिन शामिल है);

# उत्पादों को साझा करने के लिए मानक निर्देशिकाएँ।
$INCLUDE = "$निर्यात/शामिल";
$LIB = "$EXPORT/lib";
$BIN = "$निर्यात/बिन";

# एक मानक निर्माण वातावरण.
$CONS = नया विपक्ष (
CPPPATH => $INCLUDE, # C संकलनों के लिए पथ शामिल करें
LIBPATH => $LIB, प्रोग्रामों को लिंक करने के लिए # लाइब्रेरी पथ
LIBS => '-lworld', # मानक पुस्तकालयों की सूची
);

क्यूडब्ल्यू बनाएं(
नमस्ते/सिपाही
विश्व/सिपाही
);

RSI विश्व निर्देशिका का भरती होनेवाला फ़ाइल इस तरह दिखती है:

# निर्देशिका दुनिया के लिए कॉन्स्क्रिप्ट फ़ाइल
आयात qw(विपक्ष में LIB शामिल है);

# इस निर्देशिका के उत्पादों को स्थापित करें
$CONS $LIB, 'libworld.a' स्थापित करें;
$CONS $INCLUDE, 'world.h' स्थापित करें;

# आंतरिक उत्पाद
लाइब्रेरी $CONS 'libworld.a', 'world.c';

और नमस्ते निर्देशिका का भरती होनेवाला फ़ाइल इस तरह दिखती है:

# हेलो डायरेक्टरी के लिए कॉन्स्क्रिप्ट फ़ाइल
आयात qw(कॉन्स बिन);

# निर्यात किए गए उत्पाद
$CONS $BIN स्थापित करें, 'हैलो';

# आंतरिक उत्पाद
कार्यक्रम $CONS 'हैलो', 'हैलो.c';

a . का निर्माण करना नमस्ते, विश्व! इस निर्देशिका संरचना के साथ प्रोग्राम, शीर्ष स्तर पर जाएँ
निर्देशिका, और उचित तर्कों के साथ 'विपक्ष' का आह्वान करें। निम्नलिखित उदाहरण में, हम
विपक्ष को निर्देशिका बनाने के लिए कहें निर्यात. एक निर्देशिका बनाने के लिए, विपक्ष पुनरावर्ती रूप से सभी का निर्माण करता है
उस निर्देशिका के भीतर ज्ञात उत्पाद (केवल तभी जब उन्हें पुनर्निर्माण की आवश्यकता हो)। यदि कोई हो
वे उत्पाद अन्य निर्देशिकाओं में अन्य उत्पादों पर निर्भर करते हैं, फिर उनका निर्माण किया जाएगा,
भी है.

% विपक्ष निर्यात
World/world.h को निर्यात/include/world.h के रूप में स्थापित करें
cc -Iexport/include -c hello/hello.c -o hello/hello.o
cc -Iexport/include -cworld/world.c -oworld/world.o
एआर आर वर्ल्ड/लिबवर्ल्ड.ए वर्ल्ड/वर्ल्ड.ओ
ar: विश्व/libworld.a बनाना
ranlib दुनिया/libworld.a
World/libworld.a को निर्यात/lib/libworld.a के रूप में स्थापित करें
cc -o हेलो/हैलो hello/hello.o -Lexport/lib -lworld
हैलो/हैलो को एक्सपोर्ट/बिन/हैलो के रूप में स्थापित करें

स्वच्छ, समझने योग्य, स्थान-स्वतंत्र लिपियों

आप देखेंगे कि दोनों भरती होनेवाला फ़ाइलें बहुत साफ-सुथरी और सटीक हैं। वे बस
निर्देशिका के उत्पाद निर्दिष्ट करें और उन उत्पादों का निर्माण कैसे करें। निर्माण निर्देश
न्यूनतम हैं: वे निर्दिष्ट करते हैं कि किस निर्माण वातावरण का उपयोग करना है, उत्पाद का नाम,
और इनपुट का नाम. यह भी ध्यान दें कि स्क्रिप्ट स्थान-स्वतंत्र हैं: यदि आप
यदि आप अपने स्रोत वृक्ष को पुनर्गठित करना चाहते हैं, तो आप ऐसा करने के लिए स्वतंत्र हैं: आपको केवल इसे बदलना होगा
के निर्माण के फ़ाइल (इस उदाहरण में), के नए स्थान निर्दिष्ट करने के लिए भरती होनेवाला फ़ाइलें।
निर्यात वृक्ष का उपयोग इस लक्ष्य को आसान बनाता है।

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

पृथक करना स्रोत और निर्माण पेड़

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

पृथक करना निर्माण और स्रोत निर्देशिकाओं का उपयोग la संपर्क आदेश

विपक्ष एक सरल तंत्र प्रदान करता है जो इन सभी आवश्यकताओं को संभालता है। 'लिंक'
इस उदाहरण के अनुसार आदेश लागू किया गया है:

लिंक 'बिल्ड' => 'src';

निर्दिष्ट निर्देशिकाएं निर्दिष्ट स्रोत निर्देशिका से ``लिंक'' हैं। मान लीजिए
कि आप एक स्रोत निर्देशिका सेटअप करें, ", उप-निर्देशिकाओं के साथ विश्व और नमस्ते इसके नीचे,
जैसा कि पिछले उदाहरण में है। फिर आप मूल बिल्ड लाइनों को प्रतिस्थापित कर सकते हैं
इस प्रकार है:

क्यूडब्ल्यू बनाएं(
बिल्ड/वर्ल्ड/कंसक्रिप्ट
बिल्ड/हैलो/कॉनस्क्रिप्ट
);

ध्यान दें कि आप इसका इलाज करते हैं भरती होनेवाला फ़ाइल को ऐसे बनाएं मानो वह बिल्ड निर्देशिका में मौजूद हो। अब अगर
आप पहले जैसा ही कमांड टाइप करें, आपको निम्नलिखित परिणाम मिलेंगे:

% विपक्ष निर्यात
बिल्ड/वर्ल्ड/वर्ल्ड.एच को एक्सपोर्ट/इनक्लूड/वर्ल्ड.एच के रूप में इंस्टॉल करें
cc -Iexport/include -c build/hello/hello.c -o build/hello/hello.o
cc -Iexport/include -c build/world/world.c -o build/world/world.o
ar r build/world/libworld.a build/world/world.o
ar: बिल्ड/वर्ल्ड/libworld.a बनाना
ranlib बिल्ड/वर्ल्ड/libworld.a
बिल्ड/वर्ल्ड/लिबवर्ल्ड.ए को एक्सपोर्ट/लिब/लिबवर्ल्ड.ए के रूप में स्थापित करें
cc -o बिल्ड/हैलो/हैलो बिल्ड/हैलो/hello.o -Lexport/lib -lworld
बिल्ड/हैलो/हैलो को एक्सपोर्ट/बिन/हैलो के रूप में स्थापित करें

फिर से, विपक्ष ने आपके लिए विवरण का ध्यान रखा है। विशेष रूप से, आप वह सब नोटिस करेंगे
बिल्ड निर्देशिका से स्रोत फ़ाइलों और ऑब्जेक्ट फ़ाइलों का उपयोग करके निर्माण किया जाता है। के लिए
उदाहरण, बिल्ड/वर्ल्ड/वर्ल्ड.ओ से संकलित है बिल्ड/वर्ल्ड/वर्ल्ड.सी, तथा
निर्यात/शामिल/विश्व.एच से स्थापित किया गया है बिल्ड/वर्ल्ड/वर्ल्ड.एच. यह अधिकांश पर पूरा हो चुका है
प्रत्येक स्रोत से आवश्यक फ़ाइलों को जोड़ने वाले ``हार्ड'' के सरल उपाय द्वारा सिस्टम
उचित निर्माण निर्देशिका में निर्देशिका।

लिंक को विपक्ष द्वारा सही ढंग से बनाए रखा जाता है, इससे कोई फर्क नहीं पड़ता कि आप स्रोत निर्देशिका में क्या करते हैं।
यदि आप किसी स्रोत फ़ाइल को संशोधित करते हैं, तो आपका संपादक इसे ``स्थान पर'' कर सकता है या इसका नाम बदल सकता है
सबसे पहले और एक नई फ़ाइल बनाएँ। बाद के मामले में, कोई भी कठिन लिंक खो जाएगा। विपक्ष होगा
अगली बार जब स्रोत फ़ाइल की आवश्यकता होगी तो इस स्थिति का पता लगाएगा और इसे पुनः लिंक करेगा
उचित रूप से।

वैसे, आप यह भी नोटिस करेंगे नहीं अंतर्निहित में परिवर्तन की आवश्यकता थी भरती होनेवाला
फ़ाइलें. और हम आगे बढ़ सकते हैं, जैसा कि हम अगले भाग में देखेंगे।

प्रकार बनाता है

नमस्ते, विश्व! एसटी केला और आड़ू ओएस

वेरिएंट बिल्ड के लिए बस एक और सरल एक्सटेंशन की आवश्यकता होती है। आइए एक उदाहरण के रूप में लेते हैं a
baNaNa और peAcH दोनों ऑपरेटिंग सिस्टम के लिए निर्माण की अनुमति देने की आवश्यकता। इस मामले में,
हम विशेष सिस्टम तक पहुंचने के लिए एनएफएस जैसे वितरित फ़ाइल सिस्टम का उपयोग कर रहे हैं, और
किसी भी दिए गए आह्वान के लिए केवल एक या दूसरे सिस्टम को संकलित करना होगा
'विपक्ष'. यहां एक तरीका है जिससे हम इसे स्थापित कर सकते हैं के निर्माण के हमारे लिए फ़ाइल नमस्ते, विश्व!
आवेदन:

# हेलो, वर्ल्ड के लिए फ़ाइल बनाएं!

मर क्यूक्यू(ओएस निर्दिष्ट किया जाना चाहिए) जब तक कि $OS = $ARG{OS};
डाई क्यूक्यू (ओएस "आड़ू" या "केला" होना चाहिए)
अगर $OS ने "आड़ू" && $OS ने "केला";

# हमारे सभी साझा उत्पाद कहां रखे जाएं.
$निर्यात = "#निर्यात/$ओएस";

निर्यात qw(विपक्ष में लिब बिन शामिल है);

# उत्पादों को साझा करने के लिए मानक निर्देशिकाएँ।
$INCLUDE = "$निर्यात/शामिल";
$LIB = "$EXPORT/lib";
$BIN = "$निर्यात/बिन";

# एक मानक निर्माण वातावरण.
$CONS = नया विपक्ष (
CPPPATH => $INCLUDE, # C संकलनों के लिए पथ शामिल करें
LIBPATH => $LIB, प्रोग्रामों को लिंक करने के लिए # लाइब्रेरी पथ
LIBS => '-lworld', # मानक पुस्तकालयों की सूची
);

# $BUILD वह जगह है जहां से हम सब कुछ प्राप्त करेंगे।
$बिल्ड = "#बिल्ड/$ओएस";

# विपक्ष को बताएं कि $BUILD के लिए स्रोत फ़ाइलें कहां हैं।
लिंक $BUILD => 'src';

निर्माण (
"$बिल्ड/हैलो/कॉनस्क्रिप्ट",
"$बिल्ड/दुनिया/कॉनस्क्रिप्ट",
);

अब यदि हम peAcH सिस्टम में लॉग इन करते हैं, तो हम अपना निर्माण कर सकते हैं नमस्ते, विश्व! उसके लिए आवेदन
मंच:

% विपक्ष निर्यात ओएस = आड़ू
बिल्ड/पीच/वर्ल्ड/वर्ल्ड.एच को एक्सपोर्ट/पीच/इनक्लूड/वर्ल्ड.एच के रूप में इंस्टॉल करें
cc -Iexport/peach/include -c build/peach/hello/hello.c -o build/peach/hello/hello.o
cc -Iexport/peach/include -c build/peach/world/world.c -o build/peach/world/world.o
एआर आर बिल्ड/पीच/वर्ल्ड/लिबवर्ल्ड.ए बिल्ड/पीच/वर्ल्ड/वर्ल्ड.ओ
ar: बिल्ड/पीच/वर्ल्ड/लिबवर्ल्ड.ए बनाना
रैनलिब बिल्ड/पीच/वर्ल्ड/लिबवर्ल्ड.ए
बिल्ड/पीच/वर्ल्ड/लिबवर्ल्ड.ए को एक्सपोर्ट/पीच/लिब/लिबवर्ल्ड.ए के रूप में इंस्टॉल करें
सीसी -ओ बिल्ड/पीच/हैलो/हैलो बिल्ड/पीच/हैलो/हैलो.ओ -लेक्सपोर्ट/पीच/लिब -एलवर्ल्ड
बिल्ड/पीच/हैलो/हैलो को एक्सपोर्ट/पीच/बिन/हैलो के रूप में स्थापित करें

विविधतायें on a विषय

इस मॉडल के अन्य रूप संभव हैं. उदाहरण के लिए, आप तय कर सकते हैं कि आप क्या चाहते हैं
अपनी शामिल फ़ाइलों को प्लेटफ़ॉर्म निर्भर और प्लेटफ़ॉर्म स्वतंत्र फ़ाइलों में अलग करने के लिए।
इस मामले में, आपको प्लेटफ़ॉर्म-निर्भर के लिए `$INCLUDE' का एक विकल्प परिभाषित करना होगा
फ़ाइलें. अधिकांश भरती होनेवाला फ़ाइलें, पूरी तरह से प्लेटफ़ॉर्म-स्वतंत्र रूप से उत्पन्न होने वाली फ़ाइलें शामिल होंगी
बदलना नहीं पड़ेगा.

आप डिबगिंग या प्रोफाइलिंग के साथ अपने पूरे सिस्टम को संकलित करने में भी सक्षम होना चाह सकते हैं,
उदाहरण के लिए, सक्षम. आप इसे उपयुक्त कमांड लाइन विकल्पों के साथ कर सकते हैं, जैसे कि
`डीबग=चालू'। इसके बाद इसे उपयुक्त प्लेटफ़ॉर्म-विशिष्ट में अनुवादित किया जाएगा
डिबगिंग को सक्षम करने की आवश्यकताएं (इसमें अनुकूलन को बंद करना शामिल हो सकता है)।
उदाहरण)। आप वैकल्पिक रूप से इन विभिन्न प्रकार की प्रणालियों के लिए नाम स्थान भिन्न-भिन्न कर सकते हैं,
लेकिन, जैसा कि हम अगले भाग में देखेंगे, ऐसा नहीं है आवश्यक ऐसा करने के लिए, चूँकि विपक्ष सुंदर है
जब आप विकल्प बदलते हैं तो चीजों को फिर से बनाने में चतुर होते हैं।

हस्ताक्षर

MD5 क्रिप्टोग्राफिक हस्ताक्षर

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

world.o:834179303 23844c0b102ecdc0b4548d1cd1cbd8c6
libworld.a:834179304 9bf6587fa06ec49d864811a105222c00

पहला नंबर एक टाइमस्टैम्प है - UNIX सिस्टम के लिए, यह आमतौर पर की संख्या है
1 जनवरी 1970 से सेकंड। दूसरा मान एमडी5 चेकसम है। मैसेज संग्रह
कलन विधि एक एल्गोरिदम है, जो एक इनपुट स्ट्रिंग दिए जाने पर, एक मजबूत क्रिप्टोग्राफ़िक की गणना करता है
उस स्ट्रिंग के लिए हस्ताक्षर. MD5 चेकसम में संग्रहित है .भेजना फ़ाइल, वास्तव में, एक है
निर्दिष्ट फ़ाइल के लिए सभी निर्भरता जानकारी को पचाना। तो, उदाहरण के लिए, के लिए
विश्व.ओ फ़ाइल, इसमें कम से कम शामिल है विश्व.सी फ़ाइल, और कोई भी हेडर फ़ाइल जो विपक्ष है
के बारे में जानता है कि प्रत्यक्ष या अप्रत्यक्ष रूप से शामिल हैं विश्व.सी। इतना ही नहीं, लेकिन
वास्तविक कमांड लाइन जिसका उपयोग उत्पन्न करने के लिए किया गया था विश्व.ओ की गणना में भी फीड किया जाता है
द सिगनेचर। इसी प्रकार, libworld.a एक हस्ताक्षर प्राप्त होता है जिसमें ``शामिल'' होता है
इसके घटकों के हस्ताक्षर (और इसलिए, सकर्मक रूप से, के हस्ताक्षर लेकिन हाल ही
घटक), साथ ही कमांड लाइन जिसने फ़ाइल बनाई।

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

ध्यान दें कि व्युत्पन्न फ़ाइल को किसी विशेष पर निर्भर होने की कोई आवश्यकता नहीं है के निर्माण के or
भरती होनेवाला फ़ाइल--यदि इन फ़ाइलों में परिवर्तन संबंधित फ़ाइल को प्रभावित करते हैं, तो यह होगा
स्वचालित रूप से इसके हस्ताक्षर में परिलक्षित होता है, क्योंकि कमांड लाइन के प्रासंगिक हिस्से हैं
हस्ताक्षर में शामिल है. असंबंधित परिवर्तनों का कोई प्रभाव नहीं पड़ेगा.

जब विपक्ष इस बात पर विचार करता है कि किसी विशेष फ़ाइल को प्राप्त करना है या नहीं, तो वह पहले इसकी गणना करता है
फ़ाइल पर अपेक्षित हस्ताक्षर. इसके बाद यह फ़ाइल के अंतिम संशोधन समय की तुलना करता है
में दर्ज समय .भेजना प्रविष्टि, यदि कोई मौजूद है। यदि ये समय मेल खाते हैं, तो
हस्ताक्षर में संग्रहीत .भेजना फ़ाइल को सटीक माना जाता है. यदि फ़ाइल पिछली है
हस्ताक्षर नए, अपेक्षित हस्ताक्षर से मेल नहीं खाता है, तो फ़ाइल को पुनः प्राप्त किया जाना चाहिए।

ध्यान दें कि जब भी किसी आश्रित फ़ाइल के बारे में कुछ भी बदलता है तो फ़ाइल पुनः प्राप्त हो जाएगी। में
विशेष रूप से, उस पर ध्यान दें कोई किसी आश्रित के संशोधन समय में परिवर्तन (आगे या)
समय में पीछे की ओर) व्युत्पन्न फ़ाइल के पुनर्संकलन को बाध्य करेगा।

इन हस्ताक्षरों का उपयोग एक अत्यंत सरल, कुशल और प्रभावी तरीका है
किसी सिस्टम की प्रतिलिपि प्रस्तुत करने योग्यता में नाटकीय रूप से सुधार करना।

हम इसे एक सरल उदाहरण से प्रदर्शित करेंगे:

# सरल "हैलो, विश्व!" फ़ाइल का निर्माण करें
$CFLAGS = '-g' यदि $ARG{DEBUG} eq 'चालू';
$CONS = नया विपक्ष(CFLAGS => $CFLAGS);
कार्यक्रम $CONS 'हैलो', 'हैलो.c';

ध्यान दें कि विपक्ष उचित समय पर कैसे पुन: संकलित होता है:

% विपक्ष नमस्ते
सीसी -सी हैलो.सी -ओ हैलो.ओ
सीसी -ओ हेलो हेलो.ओ
% विपक्ष नमस्ते
विपक्ष: "हैलो" अद्यतित है।
% विपक्ष DEBUG=हैलो पर
सीसी -जी -सी हैलो.सी -ओ हैलो.ओ
सीसी -ओ हेलो हेलो.ओ
% विपक्ष DEBUG=हैलो पर
विपक्ष: "हैलो" अद्यतित है।
% विपक्ष नमस्ते
सीसी -सी हैलो.सी -ओ हैलो.ओ
सीसी -ओ हेलो हेलो.ओ

कोड डेटा संग्रह स्थान

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

कोष

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

निम्नलिखित पंक्तियों में ए के निर्माण के फ़ाइल विपक्ष को पहले देखने का निर्देश देगी
/usr/प्रयोग/भंडार निर्देशिका और फिर के अंतर्गत /usr/उत्पाद/भंडार निर्देशिका:

भंडार qw (
/usr/प्रयोग/भंडार
/usr/उत्पाद/भंडार
);

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

विपक्ष रिपॉजिटरी निर्देशिकाओं की एक वैश्विक सूची बनाए रखता है। विपक्ष को ख़त्म कर देगा
वर्तमान निर्देशिका, और सूची से कोई भी गैर-मौजूद निर्देशिका।

खोज la के निर्माण के पट्टिका in a कोष

विपक्ष भी खोजेगा के निर्माण के और भरती होनेवाला रिपॉजिटरी ट्री या ट्री में फ़ाइलें।
हालाँकि, यह मुर्गी और अंडे की स्थिति की ओर ले जाता है: आप एक भंडार वृक्ष में कैसे दिखते हैं
एक के लिए के निर्माण के फ़ाइल अगर के निर्माण के फ़ाइल आपको बताती है कि रिपॉजिटरी कहाँ है? पाने के
इसके आसपास, रिपॉजिटरी को कमांड लाइन पर `-R' विकल्पों के माध्यम से निर्दिष्ट किया जा सकता है:

% विपक्ष -R /usr/प्रयोग/भंडार -R /usr/उत्पाद/भंडार।

में निर्दिष्ट कोई भी रिपॉजिटरी निर्देशिका के निर्माण के or भरती होनेवाला फ़ाइलें संलग्न की जाएंगी
कमांड-लाइन `-R' विकल्पों द्वारा निर्दिष्ट रिपोजिटरी निर्देशिकाओं के लिए।

कोष स्रोत फ़ाइलों

यदि स्रोत कोड (शामिल करें) भरती होनेवाला फ़ाइल) के लाइब्रेरी संस्करण के लिए नमस्ते,
विश्व! सी एप्लिकेशन एक रिपॉजिटरी में है (बिना किसी व्युत्पन्न फ़ाइल के), विपक्ष इसका उपयोग करेगा
स्थानीय ऑब्जेक्ट फ़ाइलें और निष्पादन योग्य फ़ाइल बनाने के लिए रिपॉजिटरी स्रोत फ़ाइलें:

% विपक्ष -R /usr/src_only/repository नमस्ते
gcc -c /usr/src_only/repository/hello.c -o hello.o
gcc -c /usr/src_only/repository/world.c -oworld.o
एआर आर लिबवर्ल्ड.ए वर्ल्ड.ओ
ar: libworld.a बनाना
ranlib libworld.a
जीसीसी -ओ हैलो hello.o libworld.a

स्थानीय स्रोत फ़ाइल बनाने से विपक्ष को उचित व्युत्पन्न फ़ाइल का पुनर्निर्माण करना पड़ेगा
फ़ाइलें:

% पिको वर्ल्ड.सी
[संपादित करें]
% विपक्ष -R /usr/src_only/repository नमस्ते
जीसीसी -सी वर्ल्ड.सी -ओ वर्ल्ड.ओ
एआर आर लिबवर्ल्ड.ए वर्ल्ड.ओ
ar: libworld.a बनाना
ranlib libworld.a
जीसीसी -ओ हैलो hello.o libworld.a

और स्थानीय स्रोत फ़ाइल को हटाने से विपक्ष व्युत्पन्न के निर्माण पर वापस लौट आएगा
रिपॉजिटरी स्रोत से फ़ाइलें:

% आरएम वर्ल्ड.सी
% विपक्ष -R /usr/src_only/repository नमस्ते
gcc -c /usr/src_only/repository/world.c -oworld.o
एआर आर लिबवर्ल्ड.ए वर्ल्ड.ओ
ar: libworld.a बनाना
ranlib libworld.a
जीसीसी -ओ हैलो hello.o libworld.a

कोष व्युत्पन्न फ़ाइलों

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

यह आमतौर पर रिपॉजिटरी में सॉफ़्टवेयर का निर्माण करके पूरा किया जाएगा (या,
वैकल्पिक रूप से, एक बिल्ड निर्देशिका में, और फिर परिणाम को रिपॉजिटरी में कॉपी करना):

% सीडी /यूएसआर/सभी/भंडार
% विपक्ष नमस्ते
जीसीसी -सी हैलो.सी -ओ हैलो.ओ
जीसीसी -सी वर्ल्ड.सी -ओ वर्ल्ड.ओ
एआर आर लिबवर्ल्ड.ए वर्ल्ड.ओ
ar: libworld.a बनाना
ranlib libworld.a
जीसीसी -ओ हैलो hello.o libworld.a

(यह सुरक्षित है भले ही के निर्माण के फ़ाइल सूचीबद्ध करती है /usr/सभी/भंडार ए में निर्देशिका
'रिपॉजिटरी' कमांड क्योंकि विपक्ष वर्तमान निर्देशिका को रिपॉजिटरी से हटा देगा
सूची।)

अब यदि हम अपने पास से एप्लिकेशन की एक प्रति बनाना चाहते हैं नमस्ते सी फ़ाइल, हमें केवल इसकी आवश्यकता है
एक आवश्यक स्रोत फ़ाइल बनाने के लिए, और विपक्ष को अन्य का उपयोग करने के लिए `-R' विकल्प का उपयोग करें
भंडार से फ़ाइलें:

% mkdir $HOME/build1
% सीडी $HOME/बिल्ड1
% एड हेलो.सी
[संपादित करें]
% विपक्ष -R /usr/all/repository नमस्ते
जीसीसी -सी हैलो.सी -ओ हैलो.ओ
जीसीसी -ओ हैलो hello.o /usr/all/repository/libworld.a

ध्यान दें कि विपक्ष ने स्थानीय को फिर से बनाने की जहमत नहीं उठाई है libworld.a लाइब्रेरी (या पुनः संकलित करें
विश्व.ओ मॉड्यूल), लेकिन इसके बजाय रिपॉजिटरी से पहले से संकलित संस्करण का उपयोग करता है।

क्योंकि विपक्ष जो एमडी5 हस्ताक्षर डालता है .भेजना फ़ाइल में टाइमस्टैम्प शामिल हैं
व्युत्पन्न फ़ाइलें, हस्ताक्षर टाइमस्टैम्प को हस्ताक्षर के लिए फ़ाइल टाइमस्टैम्प से मेल खाना चाहिए
वैध माना जायेगा.

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

रिपॉजिटरी_सिग_टाइम्स_ओके 0;

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

स्थानीय प्रतियां of फ़ाइलों

यदि रिपॉजिटरी ट्री में किसी बिल्ड के पूर्ण परिणाम शामिल हैं, और हम इससे निर्माण करने का प्रयास करते हैं
हमारे स्थानीय पेड़ में बिना किसी फ़ाइल के भंडार, कुछ हद तक आश्चर्यजनक
ह ाेती है:

% mkdir $HOME/build2
% सीडी $HOME/बिल्ड2
% विपक्ष -R /usr/all/repository नमस्ते
विपक्ष: "हैलो" अद्यतित है।

विपक्ष ऐसा क्यों कहता है कि नमस्ते कोई प्रोग्राम नहीं होने पर प्रोग्राम अद्यतित होता है नमस्ते कार्यक्रम में
स्थानीय निर्माण निर्देशिका? क्योंकि भंडार (स्थानीय निर्देशिका नहीं) में शामिल है
आधुनिकतम नमस्ते कार्यक्रम, और विपक्ष सही ढंग से निर्धारित करता है कि कुछ भी करने की आवश्यकता नहीं है
फ़ाइल की इस अद्यतन प्रति को पुनः बनाएँ।

हालाँकि, कई बार यह सुनिश्चित करना उचित होता है कि किसी की स्थानीय प्रतिलिपि
फ़ाइल हमेशा मौजूद रहती है. उदाहरण के लिए, एक पैकेजिंग या परीक्षण स्क्रिप्ट यह निश्चित मान सकती है
जेनरेट की गई फ़ाइलें स्थानीय रूप से मौजूद हैं। इन सहायक लिपियों से अवगत कराने के बजाय
रिपॉजिटरी निर्देशिका में, 'स्थानीय' कमांड को इसमें जोड़ा जा सकता है के निर्माण के or भरती होनेवाला फ़ाइल
निर्दिष्ट करें कि एक निश्चित फ़ाइल या फ़ाइलें स्थानीय बिल्ड निर्देशिका में दिखाई देनी चाहिए:

स्थानीय क्यूडब्ल्यू(
नमस्ते
);

फिर, यदि हम उसी कमांड को दोबारा चलाते हैं, तो विपक्ष प्रोग्राम की एक स्थानीय प्रतिलिपि बना देगा
रिपॉजिटरी कॉपी (आपको बता रही है कि यह ऐसा कर रही है):

% विपक्ष -R /usr/all/repository नमस्ते
/usr/all/repository/hello से हैलो की स्थानीय प्रति
विपक्ष: "हैलो" अद्यतित है।

ध्यान दें, क्योंकि स्थानीय प्रतिलिपि बनाने के कार्य को "निर्माण" नहीं माना जाता है
नमस्ते फ़ाइल, विपक्ष अभी भी रिपोर्ट करता है कि यह अद्यतित है।

स्थानीय प्रतिलिपियाँ बनाना उन फ़ाइलों के लिए सबसे उपयोगी है जिन्हें किसी में स्थापित किया जा रहा है
मध्यवर्ती निर्देशिका (अन्य निर्देशिकाओं के साथ साझा करने के लिए) 'इंस्टॉल' कमांड के माध्यम से।
किसी फ़ाइल के लिए 'इंस्टॉल' कमांड के साथ एक सहयोगी 'लोकल' कमांड भी शामिल है
सामान्य बात यह है कि विपक्ष दोनों को करने के लिए एक सुविधाजनक तरीके के रूप में `Install_Local' कमांड प्रदान करता है:

इंस्टाल_लोकल $env, '#export', 'hello';

बिल्कुल बराबर है:

$env '#export', 'hello' स्थापित करें;
स्थानीय '#निर्यात/हैलो';

'लोकल' और 'इंस्टॉल_लोकल' दोनों कमांड लोकल को अपडेट करते हैं .भेजना के साथ फाइल करें
उपयुक्त फ़ाइल हस्ताक्षर, ताकि भविष्य का निर्माण सही ढंग से किया जा सके।

कोष निर्भरता विश्लेषण

इसकी अंतर्निहित स्कैनिंग के कारण, विपक्ष निर्दिष्ट रिपॉजिटरी पेड़ों को शामिल करने के लिए खोजेगा
.h फ़ाइलें. हालाँकि, जब तक कंपाइलर को रिपॉजिटरी पेड़ों के बारे में भी पता नहीं चलता, तब तक ऐसा ही रहेगा
ढूंढने में असमर्थ .h फ़ाइलें जो केवल रिपॉजिटरी में मौजूद हैं। यदि, उदाहरण के लिए, नमस्ते सी
फ़ाइल में शामिल है हैलो है इसकी वर्तमान निर्देशिका में फ़ाइल करें:

% विपक्ष -R /usr/all/repository नमस्ते
gcc -c /usr/all/repository/hello.c -o hello.o
/usr/all/repository/hello.c:1: hello.h: ऐसी कोई फ़ाइल या निर्देशिका नहीं

इस समस्या का समाधान निर्माण परिवेश पर कुछ आवश्यकताओं को लागू करता है
परिभाषित और जिस तरह से C `#include' प्रीप्रोसेसर निर्देश का उपयोग फ़ाइलों को शामिल करने के लिए किया जाता है।

कंपाइलर को रिपॉजिटरी पेड़ों के बारे में सूचित करने के लिए, विपक्ष उचित `-I' जोड़ देगा
संकलन आदेशों के लिए झंडे। इसका मतलब है कि `CPPPATH' वेरिएबल में
निर्माण परिवेश में खोजी जाने वाली सभी उपनिर्देशिकाओं को स्पष्ट रूप से निर्दिष्ट किया जाना चाहिए
वर्तमान निर्देशिका सहित सम्मिलित फ़ाइलों के लिए। नतीजतन, हम उपरोक्त को ठीक कर सकते हैं
उदाहरण के लिए पर्यावरण निर्माण में परिवर्तन करके के निर्माण के फ़ाइल इस प्रकार है:

$env = नया विपक्ष(
सीसी => 'जीसीसी',
CPPPATH => '.',
LIBS => 'libworld.a',
);

'CPPPATH' वेरिएबल की परिभाषा के कारण, जब हम इसे दोबारा निष्पादित करते हैं, तो यह प्राप्त होता है
आदेश:

% विपक्ष -R /usr/all/repository नमस्ते
जीसीसी -सी -आई. -I/usr/all/repository /usr/all/repository/hello.c -o hello.o
जीसीसी -ओ हैलो hello.o /usr/all/repository/libworld.a

सी प्रीप्रोसेसर के लिए `-I' झंडों का क्रम दोहराया जाता है, वही रिपॉजिटरी-
निर्देशिका खोज पथ जिसे विपक्ष अपनी निर्भरता विश्लेषण के लिए उपयोग करता है। अगर वहाँ
एकाधिक रिपॉजिटरी और एकाधिक `CPPPATH' निर्देशिकाएं, विपक्ष रिपॉजिटरी को जोड़ देगा
प्रत्येक `CPPPATH' निर्देशिका की शुरुआत में निर्देशिकाएँ, संख्या को तेजी से गुणा करना
'-I' झंडों का. एक चरम उदाहरण के रूप में, ए के निर्माण के फ़ाइल युक्त:

भंडार qw(
/यू1
/यू2
);

$env = नया विपक्ष(
CPPPATH => 'ए:बी:सी',
);

इसका एक संकलन आदेश प्राप्त होगा:

cc -Ia -I/u1/a -I/u2/a -Ib -I/u1/b -I/u2/b -Ic -I/u1/c -I/u2/c -c hello.c -o हेलो.ओ

क्योंकि विपक्ष संकलक के `-I' झंडे पर निर्भर करता है ताकि क्रम को संप्रेषित किया जा सके
रिपॉजिटरी निर्देशिकाओं की खोज की जानी चाहिए, रिपॉजिटरी निर्देशिकाओं का प्रबंधन विपक्ष है
आपके सी में `#include' निर्देशों पर डबल-कोट्स का उपयोग करने के साथ मौलिक रूप से असंगत है
सोर्स कोड:

#शामिल "फ़ाइल.एच" /* इस तरह डबल-कोट्स का उपयोग न करें */

ऐसा इसलिए है क्योंकि अधिकांश सी प्रीप्रोसेसर, जब इस तरह के निर्देश का सामना करते हैं, तो हमेशा पहले होंगे
स्रोत फ़ाइल वाली निर्देशिका खोजें। यह विस्तृत `-I' को कमज़ोर करता है
विकल्प जो प्रीप्रोसेसर को उसकी पसंदीदा खोज के अनुरूप बनाने के लिए विपक्ष का निर्माण करता है
पथ।

नतीजतन, विपक्ष में रिपॉजिटरी पेड़ों का उपयोग करते समय, हमेशा शामिल करने के लिए कोण-कोष्ठक का उपयोग करें
फ़ाइलें:

#शामिल करना /* इसके बजाय कोण-कोष्ठक का उपयोग करें */

रिपोजिटरी_सूची

विपक्ष सभी रिपॉजिटरी निर्देशिकाओं की सूची वापस करने के लिए एक `रिपॉजिटरी_लिस्ट' कमांड प्रदान करता है
उनके वर्तमान खोज क्रम में। इसका उपयोग डिबगिंग के लिए, या अधिक जटिल पर्ल करने के लिए किया जा सकता है
सामग्री:

@सूची = रिपॉजिटरी_लिस्ट;
प्रिंट जॉइन('', @सूची), "\n";

कोष बातचीत साथ में अन्य नुकसान विशेषताएं

रिपॉजिटरी पेड़ों का विपक्ष का प्रबंधन अन्य विपक्ष सुविधाओं के साथ सही ढंग से इंटरैक्ट करता है - जो कि है
कहने का तात्पर्य यह है कि यह आम तौर पर वही करता है जिसकी आप अपेक्षा करते हैं।

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

चूक लक्ष्य

अब तक, हमने निर्माण के स्पष्ट लक्ष्य के साथ विपक्ष को लागू करने का प्रदर्शन किया है:

% विपक्ष नमस्ते

आम तौर पर, जब तक कोई लक्ष्य निर्दिष्ट नहीं किया जाता है, तब तक विपक्ष कुछ भी नहीं बनाता है, लेकिन '.' निर्दिष्ट करता है।
(वर्तमान निर्देशिका) सब कुछ बनाएगी:

% विपक्ष # कुछ भी नहीं बनाता है

% दोष । # सब कुछ शीर्ष-स्तरीय निर्देशिका के अंतर्गत बनाता है

किसी में 'डिफ़ॉल्ट' विधि जोड़ना के निर्माण के or भरती होनेवाला फ़ाइल निर्दिष्ट को जोड़ देगी
डिफ़ॉल्ट लक्ष्यों की सूची में लक्ष्य। यदि कोई नहीं है तो विपक्ष इन डिफॉल्ट्स का निर्माण करेगा
कमांड लाइन पर निर्दिष्ट लक्ष्य। तो निम्न पंक्ति को शीर्ष-स्तर पर जोड़ना
के निर्माण के फ़ाइल डिफ़ॉल्ट रूप से सब कुछ बनाने के मेक के विशिष्ट व्यवहार की नकल करेगी:

गलती करना '।';

निम्नलिखित को जोड़ा जाएगा नमस्ते और अलविदा आदेश (उसी निर्देशिका में
के निर्माण के or भरती होनेवाला फ़ाइल) डिफ़ॉल्ट सूची में:

डिफ़ॉल्ट qw(
नमस्ते
अलविदा
);

डिफ़ॉल्ट सूची में लक्ष्य जोड़ने के लिए 'डिफ़ॉल्ट' विधि का उपयोग एक से अधिक बार किया जा सकता है।

चयनात्मक बनाता है

विपक्ष दिए गए निर्माण के आकार को कम करने के लिए दो तरीके प्रदान करता है। पहला निर्दिष्ट करके है
कमांड लाइन पर लक्ष्य, और दूसरा बिल्ड ट्री को काटने की एक विधि है। कुंआ
पहले लक्ष्य विशिष्टता पर विचार करें.

चयनात्मक को लक्षित

मेक की तरह, विपक्ष कमांड लाइन पर ``लक्ष्य'' के विनिर्देशन की अनुमति देता है। विपक्ष लक्ष्य
या तो फ़ाइलें या निर्देशिकाएँ हो सकती हैं। जब कोई निर्देशिका निर्दिष्ट की जाती है, तो यह बस एक संक्षिप्त-
प्रत्येक व्युत्पन्न उत्पाद के लिए हस्त संकेतन - जिसके बारे में विपक्ष को पता है - निर्दिष्ट में
निर्देशिका और नीचे। उदाहरण के लिए:

% विपक्ष बिल्ड/हैलो/हैलो.ओ

मतलब निर्माण हेलो.ओ और वह सब कुछ हेलो.ओ आवश्यकता हो सकती है। यह पहले से है
के संस्करण नमस्ते, विश्व! जिस कार्यक्रम में हेलो.ओ पर निर्भर
निर्यात/शामिल/विश्व.एच. यदि वह फ़ाइल अद्यतित नहीं है (क्योंकि किसी ने संशोधित किया है
src/world/world.h), तो इसे फिर से बनाया जाएगा, भले ही यह किसी दूरस्थ निर्देशिका में हो
निर्माण/हैलो.

इस उदाहरण में:

% विपक्ष निर्माण

में सब कुछ निर्माण यदि आवश्यक हो तो निर्देशिका बनाई जाती है। फिर, इससे अधिक फ़ाइलें उत्पन्न हो सकती हैं
निर्मित किया जाने वाला है। विशेषकर, दोनों निर्यात/शामिल/विश्व.एच और निर्यात/lib/libworld.a रहे
द्वारा आवश्यक है निर्माण/हैलो निर्देशिका, और यदि वे पुरानी हैं तो उन्हें बनाया जाएगा।

यदि हम ऐसा करते हैं, तो इसके बजाय:

% विपक्ष निर्यात

तभी निर्यात निर्देशिका में स्थापित की जाने वाली फ़ाइलों को फिर से बनाया जाएगा, यदि
आवश्यक, और फिर वहां स्थापित किया गया। ध्यान दें कि `cons बिल्ड' ऐसी फ़ाइलें बना सकता है जो `cons
निर्यात' नहीं बनता है, और इसके विपरीत।

नहीं ``विशेष'' लक्ष्य

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

% विपक्ष परीक्षण

सभी परीक्षणों का निर्माण करेगा.

% विपक्ष निर्यात

सिस्टम का उत्पादन संस्करण तैयार करेगा (लेकिन परीक्षण नहीं), और:

% विपक्ष निर्माण

संभवतः इससे बचना चाहिए (क्योंकि यह अनावश्यक रूप से परीक्षण संकलित करेगा)।

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

यदि आप पेड़ में पूरी तरह से सब कुछ बनाना चाहते हैं (आपके पास जो भी विकल्प हों, उसके अधीन)।
चुनें), आप इसका उपयोग कर सकते हैं:

% दोष ।

यह विशेष रूप से कुशल नहीं है, क्योंकि यह अनावश्यक रूप से सभी पेड़ों पर चल देगा,
स्रोत वृक्ष सहित। निस्संदेह, स्रोत वृक्ष में निर्माण योग्य वस्तुएं हो सकती हैं
यह--आपको ऐसा करने से कोई नहीं रोकता, भले ही आप सामान्य रूप से एक अलग बिल्ड बनाते हों
पेड़.

बनाएँ छंटाई

लक्ष्य चयन के साथ-साथ, निर्माण छंटाई के दायरे को कम करने के लिए उपयोग किया जा सकता है
निर्माण। पिछले peAcH और baNaNa उदाहरण में, हम पहले ही देख चुके हैं कि स्क्रिप्ट कैसे संचालित होती है
बिल्ड प्रूनिंग का उपयोग किसी भी दिए गए संभावित बिल्ड का केवल आधा हिस्सा उपलब्ध कराने के लिए किया जा सकता है
'विपक्ष' का आह्वान. विपक्ष एक सुविधा के रूप में, एक कमांड लाइन कन्वेंशन भी प्रदान करता है
आपको कौन सा निर्दिष्ट करने की अनुमति देता है भरती होनेवाला फ़ाइलें वास्तव में ``निर्मित'' होती हैं--अर्थात् सम्मिलित होती हैं
निर्माण वृक्ष में. उदाहरण के लिए:

% विपक्ष निर्माण +दुनिया

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

उपरोक्त उदाहरण में, नमस्ते प्रोग्राम नहीं बनाया जाएगा, क्योंकि विपक्ष के पास कोई नहीं होगा
लिपि का ज्ञान नमस्ते/सिपाही। libworld.a हालाँकि, यदि संग्रह बनाया जाएगा
होना चाहिए.

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

अस्थायी ओवरराइड

विपक्ष किसी निर्माण के पहलुओं को ओवरराइड करने के लिए एक बहुत ही सरल तंत्र प्रदान करता है। सार है
कि आप एक ओवरराइड फ़ाइल लिखें जिसमें एक या अधिक `ओवरराइड' कमांड हों, और आप
जब आप `cons' चलाते हैं, तो इसे कमांड लाइन पर निर्दिष्ट करें:

% विपक्ष -ओ निर्यात पर

का निर्माण करेगा निर्यात निर्देशिका, सभी व्युत्पन्न फ़ाइलें मौजूद ओवरराइड के अधीन हैं
में के ऊपर फ़ाइल। यदि आप `-o' विकल्प छोड़ देते हैं, तो सभी आवश्यक चीज़ें हटा दें
सभी ओवरराइड का पुनर्निर्माण किया जाएगा.

अधिभावी वातावरण चर

ओवरराइड फ़ाइल में दो प्रकार के ओवरराइड हो सकते हैं. पहला आने वाला वातावरण है
चर। ये आम तौर पर इनके द्वारा पहुंच योग्य होते हैं के निर्माण के `%ENV' हैश से फ़ाइल
चर। इन्हें सेट करके ओवरराइड फ़ाइल में तुच्छ रूप से ओवरराइड किया जा सकता है
`%ENV' के उपयुक्त तत्व (इन्हें उपयोगकर्ता के वातावरण में ओवरराइड भी किया जा सकता है,
बेशक)।

RSI अधिरोहण आदेश

दूसरे प्रकार का ओवरराइड 'ओवरराइड' कमांड के साथ पूरा किया जाता है, जो दिखता है
इस:

अवहेलना , => , => , ...;

नियमित अभिव्यक्ति regexp उम्मीदवार की प्रत्येक व्युत्पन्न फ़ाइल से मिलान किया जाता है
निर्माण के लिए. यदि व्युत्पन्न फ़ाइल मेल खाती है, तो चर/मूल्य जोड़े का उपयोग किया जाता है
व्युत्पन्न फ़ाइल से जुड़े निर्माण वातावरण में मानों को ओवरराइड करें।

आइए मान लें कि हमारे पास इस तरह का निर्माण वातावरण है:

$CONS = नया विपक्ष(
सीओपीटी => '',
सीडीबीजी => '-जी',
CFLAGS => '%COPT %CDBG',
);

फिर यदि हमारे पास ओवरराइड फ़ाइल है के ऊपर इस आदेश से युक्त:

ओवरराइड '\.o$', COPT => '-O', CDBG => '';

फिर `-o ओवर' के साथ कोई `विपक्ष' आह्वान जो बनाता है .o इस वातावरण के माध्यम से फ़ाइलें होंगी
उन्हें `-O' और नहीं `-g' के साथ संकलित करें। बेशक, ओवरराइड हो सकता है
रेगुलर एक्सप्रेशन के उचित चयन द्वारा एकल निर्देशिका तक सीमित।

यहां हैलो, वर्ल्ड का मूल संस्करण है! कार्यक्रम, इस वातावरण के साथ बनाया गया।
ध्यान दें कि जब ओवरराइड लागू किया जाता है या हटा दिया जाता है तो विपक्ष उचित टुकड़ों का पुनर्निर्माण करता है:

% विपक्ष नमस्ते
सीसी -जी -सी हैलो.सी -ओ हैलो.ओ
सीसी -ओ हेलो हेलो.ओ
% विपक्ष -ओ नमस्ते पर
सीसी -ओ -सी हैलो.सी -ओ हैलो.ओ
सीसी -ओ हेलो हेलो.ओ
% विपक्ष -ओ नमस्ते पर
विपक्ष: "हैलो" अद्यतित है।
% विपक्ष नमस्ते
सीसी -जी -सी हैलो.सी -ओ हैलो.ओ
सीसी -ओ हेलो हेलो.ओ

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

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

अधिक on निर्माण वातावरण

चूक निर्माण चर

हमने 'ए' की अवधारणा का उल्लेख और उपयोग किया है निर्माण वातावरण, कई बार में
पूर्ववर्ती पृष्ठ. अब इसे थोड़ा और ठोस बनाने का समय आ गया है। निम्नलिखित के साथ
बयान:

$env = नया विपक्ष();

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

सीसी => 'सीसी',
CFLAGS => '',
CCCOM => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
INCDIRPREFIX => '-I',
CXX => '%CC',
CXXFLAGS => '%CFLAGS',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS -c %< -o %>',
लिंक => '%CXX',
LINKCOM => '%LINK %LDFLAGS -o %> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD -r -o %> %<',
LIBDIRPREFIX => '-L',
एआर => 'एआर',
ARFLAGS => 'आर',
ARCOM => "%AR %ARFLAGS %> %<\n%RANLIB %>",
रैनलिब => 'रैनलिब',
AS => 'जैसा',
ASFLAGS => '',
ASCOM => '%AS %ASFLAGS %< -o %>',
एलडी => 'एलडी',
एलडीएफएलजीएस => '',
प्रीफ्लिब => 'लिब',
SUFLIB => '.a',
SUFLIBS => '.so:.a',
SUFOBJ => '.o',
ENV => { 'पथ' => '/ bin:/ Usr / bin' },

Win32 सिस्टम (Windows NT) पर, निम्नलिखित निर्माण चर को ओवरराइड किया गया है
चूक:

सीसी => 'सीएल',
CFLAGS => '/नोलोगो',
CCCOM => '%CC %CFLAGS %_IFLAGS /c %< /Fo%>',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS /c %< /Fo%>',
INCDIRPREFIX => '/I',
लिंक => 'लिंक',
LINKCOM => '%LINK %LDFLAGS /out:%> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD /r /o %> %<',
LIBDIRPREFIX => '/LIBPATH:',
एआर => 'lib',
ARFLAGS => '/nologo',
ARCOM => "%AR %ARFLAGS /आउट:%> %<",
रैनलिब => '',
एलडी => 'लिंक',
LDFLAGS => '/नोलोगो',
प्रीफ्लिब => '',
SUFEXE => '.exe',
SUFLIB => '.lib',
SUFLIBS => '.dll:.lib',
SUFOBJ => '.obj',

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

ऑब्जेक्ट $env 'foo.c', 'bar.c';

यदि आवश्यक हो तो यह उत्पादन की व्यवस्था करेगा, फू.ओ और बार.ओ. लागू किया गया आदेश सरल है
`%CCCOM', जो आवश्यक बाहरी कमांड के लिए प्रतिस्थापन के माध्यम से विस्तारित होता है
प्रत्येक वस्तु का निर्माण करने के लिए. हम 'कमांड' के तहत आगे प्रतिस्थापन नियमों का पता लगाएंगे
विधि, नीचे.

निर्माण चर का उपयोग अन्य उद्देश्यों के लिए भी किया जाता है। उदाहरण के लिए, `CPPPATH' है
निर्देशिकाओं को शामिल करने के लिए कोलन से अलग किए गए पथ को निर्दिष्ट करने के लिए उपयोग किया जाता है। ये होने का इरादा है
सी प्रीप्रोसेसर को पारित किया गया और सी-फ़ाइल स्कैनिंग मशीनरी द्वारा भी उपयोग किया जाता है
C संकलन में शामिल निर्भरताएँ निर्धारित करें। से शुरू होने वाले वेरिएबल
अंडरस्कोर, विभिन्न तरीकों से बनाए जाते हैं, और इन्हें आम तौर पर ``आंतरिक'' माना जाना चाहिए
चर। उदाहरण के लिए, जब एक विधि को कॉल किया जाता है जो किसी ऑब्जेक्ट के निर्माण की मांग करती है
C स्रोत से, वेरिएबल `_IFLAGS' बनाया गया है: यह `-I' स्विच से मेल खाता है
C कंपाइलर द्वारा `CPPPATH' द्वारा निर्दिष्ट निर्देशिकाओं का प्रतिनिधित्व करने के लिए आवश्यक है।

ध्यान दें कि, किसी विशेष वातावरण के लिए, एक चर का मान एक बार और फिर निर्धारित किया जाता है
कभी भी रीसेट न करें (एक वेरिएबल को बदलने के लिए, आपको एक नया वातावरण बनाना होगा। तरीके प्रदान किए गए हैं
इस उद्देश्य के लिए मौजूदा वातावरण की प्रतिलिपि बनाने के लिए)। कुछ आंतरिक चर, जैसे
`_IFLAGS' मांग पर बनाए जाते हैं, लेकिन एक बार सेट होने के बाद, वे जीवन भर के लिए स्थिर रहते हैं
पर्यावरण.

`CFLAGS', `LDFLAGS', और `ARFLAGS' वेरिएबल सभी विकल्पों को पारित करने के लिए एक स्थान प्रदान करते हैं
क्रमशः कंपाइलर, लोडर और आर्काइवर। कम स्पष्ट रूप से, 'INCDIRPREFIX'
वेरिएबल प्रत्येक शामिल की शुरुआत में जोड़े जाने वाले विकल्प स्ट्रिंग को निर्दिष्ट करता है
निर्देशिका ताकि कंपाइलर को पता चले कि कहां ढूंढना है .h फ़ाइलें. इसी प्रकार,
`LIBDIRPREFIX' वैरिएबल शुरुआत में जोड़े जाने वाले विकल्प स्ट्रिंग को निर्दिष्ट करता है
प्रत्येक निर्देशिका जिसमें लिंकर को पुस्तकालयों की खोज करनी चाहिए।

एक अन्य वेरिएबल, 'ईएनवी' का उपयोग निष्पादन के दौरान सिस्टम वातावरण को निर्धारित करने के लिए किया जाता है
किसी बाहरी आदेश का. डिफ़ॉल्ट रूप से, सेट किया गया एकमात्र पर्यावरण चर `PATH' है,
जो UNIX कमांड के लिए निष्पादन पथ है। अधिकतम प्रतिलिपि प्रस्तुत करने योग्यता के लिए, आपको ऐसा करना चाहिए
वास्तव में अपने शीर्ष स्तर पर, अपना स्वयं का निष्पादन पथ निर्धारित करने की व्यवस्था करें के निर्माण के फ़ाइल (या
शायद पर्ल `यूज़' कमांड के साथ एक उपयुक्त निर्माण पैकेज आयात करके)।
डिफ़ॉल्ट वैरिएबल का उद्देश्य आपको जमीन से उतारना है।

प्रक्षेप करना निर्माण चर

निर्माण पर्यावरण चर को स्रोत और लक्ष्य फ़ाइल नामों में प्रक्षेपित किया जा सकता है
निर्माण चर नाम को `%' से पहले जोड़कर।

$env = नया विपक्ष(
DESTDIR => 'प्रोग्राम',
एसआरसीडीआईआर => 'src',
);
प्रोग्राम $env '%DESTDIR/hello', '%SRCDIR/hello.c';

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

चूक निर्माण तरीकों

डिफ़ॉल्ट निर्माण विधियों की सूची में निम्नलिखित शामिल हैं:

RSI 'नया' निर्माता

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

$env = नया विपक्ष( );

जो वातावरण आपको वापस मिलता है वह पैकेज 'विपक्ष' में धन्य है, जिसका अर्थ है कि यह होगा
इसके साथ नीचे वर्णित डिफ़ॉल्ट विधियाँ संबद्ध की गई हैं। व्यक्तिगत निर्माण
ओवरराइड सूची में नाम/मूल्य जोड़े प्रदान करके वेरिएबल्स को ओवरराइड किया जा सकता है। ध्यान दें कि
किसी भी कमांड पर्यावरण चर (यानी 'ईएनवी' के तहत कुछ भी) को ओवरराइड करने के लिए, आपको यह करना होगा
उन सभी को ओवरराइड करें. आप 'कॉपी' पद्धति का उपयोग करके इस कठिनाई से निजात पा सकते हैं
मौजूदा निर्माण वातावरण.

RSI 'क्लोन' तरीका

'क्लोन' विधि मौजूदा निर्माण परिवेश का क्लोन बनाती है, और हो भी सकती है
निम्नलिखित उदाहरण में कहा गया है:

$env2 = $env1->क्लोन( );

आप इससे भिन्न वातावरण बनाने के लिए सामान्य तरीके से ओवरराइड प्रदान कर सकते हैं
मूल। यदि आप उसी परिवेश के लिए एक नया नाम चाहते हैं (जो तब सहायक हो सकता है
मौजूदा घटकों में परिवेश निर्यात करना), आप बस सरल असाइनमेंट का उपयोग कर सकते हैं।

RSI 'कॉपी' तरीका

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

%env = $env1->कॉपी( );

'ईएनवी' का मान, जो स्वयं एक हैश है, को भी एक नए हैश में कॉपी किया जाता है, इसलिए यह हो सकता है
मूल परिवेश को प्रभावित करने के डर के बिना बदला गया। तो, उदाहरण के लिए, यदि आप वास्तव में
यदि आप डिफ़ॉल्ट वातावरण में केवल `PATH' वेरिएबल को ओवरराइड करना चाहते हैं, तो आप ऐसा कर सकते हैं
इस प्रकार है:

%cons = new cons()->copy();
$cons{ENV}{PATH} = " ";
$विपक्ष = नया विपक्ष(%विपक्ष);

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

RSI `इंस्टॉल करें' तरीका

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

$env इंस्टॉल करें , ;

ध्यान दें, जबकि स्थापित की जाने वाली फ़ाइलों को मनमाने ढंग से नाम दिया जा सकता है, केवल अंतिम
प्रत्येक नाम का घटक स्थापित लक्ष्य नाम के लिए उपयोग किया जाता है। तो, उदाहरण के लिए, यदि आप
स्थापित करने की व्यवस्था करें फू/बार in आधार, यह एक बनाएगा बार में दायर आधार निर्देशिका (नहीं
फू/बार).

RSI 'इंस्टॉल करें' तरीका

'InstallAs' विधि निर्दिष्ट स्रोत के लिए व्यवस्था करती है पट्टिका(ओं) के रूप में स्थापित किया जाना है
निर्दिष्ट लक्ष्य पट्टिका(एस)। एकाधिक फ़ाइलों को फ़ाइल सूची के रूप में निर्दिष्ट किया जाना चाहिए।
इंस्टॉलेशन अनुकूलित है: यदि फ़ाइल को लिंक किया जा सकता है तो उसे कॉपी नहीं किया जाएगा। यदि यह नहीं है
वांछित व्यवहार के कारण, आपको फ़ाइल को स्थापित करने के लिए एक अलग विधि का उपयोग करने की आवश्यकता होगी। यह है
इस प्रकार बुलाया गया:

'इंस्टॉलएज़' दो तरह से काम करता है:

एकल फ़ाइल स्थापना:

$env TgtFile, SrcFile के रूप में इंस्टॉल करें;

एकाधिक फ़ाइल इंस्टॉल:

InstallAs $env ['tgt1', 'tgt2'], ['src1', 'src2'];

या, यहाँ तक कि:

@srcs = qw(src1 src2 src3);
@tgts = qw(tgt1 tgt2 tgt3);
InstallAs $env [@tgts], [@srcs];

लक्ष्य और स्रोत सूचियाँ दोनों समान लंबाई की होनी चाहिए।

RSI 'कीमती' तरीका

'प्रेशियस' विधि विपक्ष से निर्दिष्ट फ़ाइल या फ़ाइलों की सूची को पहले न हटाने के लिए कहती है
उन्हें फिर से बनाना. इसे इस प्रकार पुकारा जाता है:

कीमती ;

यह पुस्तकालयों या डीबग में वृद्धिशील अद्यतन की अनुमति देने के लिए विशेष रूप से उपयोगी है
सूचना फ़ाइलें जिन्हें हर बार नए सिरे से बनाने के बजाय अद्यतन किया जाता है। विपक्ष अभी भी होगा
`-r' ध्वज निर्दिष्ट होने पर फ़ाइलें हटा दें।

RSI 'कमांड' तरीका

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

कमांड $env , , ;

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

निर्माण कमांड के भीतर, निर्माण वातावरण से कोई भी चर हो सकता है
निर्माण चर के नाम के पहले `%' लगाकर प्रस्तुत किया गया। यह पुनरावर्ती है:
कमांड का विस्तार तब तक किया जाता है जब तक कोई और प्रतिस्थापन नहीं किया जा सके। यदि कोई निर्माण
वेरिएबल को पर्यावरण में परिभाषित नहीं किया गया है, तो शून्य स्ट्रिंग को प्रतिस्थापित किया जाएगा। ए
निर्माण आदेश में दोगुने `%%' को एकल `%' से प्रतिस्थापित किया जाएगा।

ऐसे कई छद्म चर हैं जिनका विस्तार भी किया जाएगा:

%> लक्ष्य फ़ाइल नाम (बहु-लक्ष्य कमांड में, यह हमेशा पहला लक्ष्य होता है
उल्लिखित)।

%0 `%>' के समान।

%1, %2, ..., %9
ये क्रमशः पहली से नौवीं इनपुट फ़ाइल को संदर्भित करते हैं।

%< इनपुट का पूरा सेट। यदि इनमें से किसी का उपयोग कहीं और किया गया है
वर्तमान कमांड लाइन (`%1', `%2', आदि के माध्यम से), तो उन्हें हटा दिया जाएगा
सूची `%<' द्वारा प्रदान की गई। a में पाए गए निम्नलिखित कमांड पर विचार करें भरती होनेवाला पट्टिका
में परीक्षण निर्देशिका:

कमांड $env 'tgt', qw(foo bar baz), qq(
इको %< -i %1 > %>
प्रतिध्वनि %< -i %2 >> %>
प्रतिध्वनि %< -i %3 >> %>
);

If TGT अद्यतन करने की आवश्यकता है, तो इसके परिणामस्वरूप निष्पादन होगा
निम्नलिखित आदेशों का पालन करते हुए, यह मानते हुए कि इसके लिए कोई रीमैपिंग स्थापित नहीं की गई है परीक्षण
निर्देशिका:

इको टेस्ट/बार टेस्ट/बाज -आई टेस्ट/फू > टेस्ट/टीजीटी
इको टेस्ट/फू टेस्ट/बाज-आई टेस्ट/बार >> टेस्ट/टीजीटी
इको टेस्ट/फू टेस्ट/बार-आई टेस्ट/बाज >> टेस्ट/टीजीटी

उपरोक्त किसी भी छद्म चर का तुरंत निम्नलिखित में से किसी एक द्वारा अनुसरण किया जा सकता है
विस्तारित पथ नाम के एक भाग का चयन करने के लिए प्रत्यय:

:a फ़ाइल नाम का पूर्ण पथ
:b निर्देशिका और फ़ाइल नाम से कोई भी प्रत्यय हटा दिया गया है
:d निर्देशिका
:f फ़ाइल नाम
:s फ़ाइल नाम प्रत्यय
:F फ़ाइल नाम से कोई भी प्रत्यय हटा दिया गया है

उपरोक्त उदाहरण को जारी रखते हुए, `%<:f' का विस्तार `foo bar baz' तक होगा, और `%':d> का विस्तार होगा
'परीक्षण' तक विस्तारित करें।

कमांड के भाग को संलग्न करके प्रोग्रामेटिक रूप से उसे फिर से लिखना संभव है
`%[' और `%]' के बीच। यह पहले शब्द के रूप में नामित निर्माण चर को कॉल करेगा
पर्ल कोड संदर्भ के रूप में कोष्ठक में संलग्न; इस कॉल के परिणामों का उपयोग किया जाएगा
कमांड लाइन में कोष्ठक की सामग्री को बदलने के लिए। उदाहरण के लिए, एक दिया गया
मौजूदा इनपुट फ़ाइल का नाम tgt.in:

@कीवर्ड्स = qw(फू बार बाज़);
$env = नया विपक्ष(X_COMMA => उप { शामिल हों(",", @_) });
कमांड $env 'tgt', 'tgt.in', qq(
इको '# कीवर्ड्स: %[X_COMMA @keywords %]' > %>
बिल्ली %< >> %>
);

यह निष्पादित करेगा:

इको '# कीवर्ड: foo,bar,baz' > tgt
cat tgt.in >> tgt

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

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

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

विस्तार के बाद, प्रत्येक कमांड स्ट्रिंग का पहला शब्द निष्पादन योग्य माना जाता है
कमांड ने `PATH' पर्यावरण चर (जो बदले में, द्वारा निर्दिष्ट किया गया है) को देखा
'ईएनवी' निर्माण चर)। यदि यह आदेश पथ पर पाया जाता है, तो लक्ष्य होगा
इस पर निर्भर रहें: इसलिए आवश्यकतानुसार कमांड स्वचालित रूप से बनाई जाएगी। इसका
सेमी-कोलन द्वारा अलग किए गए कुछ शेल्स में मल्टी-पार्ट कमांड लिखना संभव है। केवल
हालाँकि, पहले कमांड शब्द पर निर्भर किया जाएगा, इसलिए यदि आप अपनी कमांड स्ट्रिंग लिखते हैं
इस तरह, आपको या तो स्पष्ट रूप से एक निर्भरता स्थापित करनी होगी ('निर्भर' विधि के साथ), या
सुनिश्चित करें कि आप जिस कमांड का उपयोग कर रहे हैं वह एक सिस्टम कमांड है जो अपेक्षित है
उपलब्ध। यदि यह उपलब्ध नहीं है, तो निस्संदेह आपको एक त्रुटि मिलेगी।

यदि कोई कमांड (यहां तक ​​कि मल्टी-लाइन कमांड में से एक भी) `[perl]' से शुरू होता है, तो शेषफल
उस कमांड लाइन का मूल्यांकन फोर्क किए जाने के बजाय रनिंग पर्ल द्वारा किया जाएगा
शंख। यदि पर्ल को पार्स करने में कोई त्रुटि होती है या यदि पर्ल एक्सप्रेशन 0 या लौटाता है
अपरिभाषित, आदेश को विफल माना जाएगा। उदाहरण के लिए, यहाँ एक सरल है
कमांड जो पर्ल से सीधे `foo' फ़ाइल बनाता है:

$env = नया विपक्ष();
कमांड $env 'foo',
qq([perl] open(FOO,'>foo');प्रिंट FOO "hi\\n"; बंद करें(FOO); 1);

ध्यान दें कि जब कमांड निष्पादित होता है, तो आप उसी पैकेज में होते हैं जब के निर्माण के
or भरती होनेवाला फ़ाइल पढ़ी गई थी, इसलिए आप उसमें परिभाषित पर्ल फ़ंक्शंस को कॉल कर सकते हैं
के निर्माण के or भरती होनेवाला फ़ाइल जिसमें `कमांड' दिखाई देता है:

$env = नया विपक्ष();
उप create_file {
मेरी $फ़ाइल = शिफ्ट;
खुला(फ़ाइल, ">$फ़ाइल");
फ़ाइल प्रिंट करें "हाय\n";
बंद करें (फ़ाइल);
1 वापसी;
}
कमांड $env 'foo', "[perl] &create_file('%>')";

पर्ल स्ट्रिंग का उपयोग व्युत्पन्न फ़ाइल के लिए हस्ताक्षर उत्पन्न करने के लिए किया जाएगा, इसलिए यदि आप
स्ट्रिंग बदलें, फ़ाइल फिर से बनाई जाएगी। आपके द्वारा कॉल किए गए किसी भी सबरूटीन की सामग्री,
हालाँकि, ये हस्ताक्षर का हिस्सा नहीं हैं, इसलिए यदि आप किसी कॉल किए गए सबरूटीन को संशोधित करते हैं जैसे
ऊपर `create_file', लक्ष्य होगा नहीं पुनर्निर्माण किया जाए. चेतावनी उपयोगकर्ता.

विपक्ष आमतौर पर किसी कमांड को निष्पादित करने से पहले प्रिंट करता है। इस व्यवहार को दबा दिया जाता है यदि
कमांड का पहला अक्षर `@' है। ध्यान दें कि आपको `@' को अलग करने की आवश्यकता हो सकती है
`@cmd' को पर्ल उद्धरण में एक सरणी की तरह दिखने से रोकने के लिए कमांड नाम या इससे बचें
ऑपरेटर जो इंटरपोलेशन करते हैं:

# पहली कमांड लाइन गलत है,
# क्योंकि "@cp" एक सरणी की तरह दिखता है
# पर्ल qq// फ़ंक्शन के लिए।
# इसके स्थान पर दूसरे फॉर्म का उपयोग करें.
कमांड $env 'foo', 'foo.in', qq(
@cp %< tempfile
@सीपी टेम्पफाइल %>
);

यदि विस्तारित कमांड लाइन में कहीं भी शेल मेटा वर्ण हैं, जैसे `<',
`>', उद्धरण, या सेमी-कोलन, तो कमांड वास्तव में a का आह्वान करके निष्पादित किया जाएगा
शंख। इसका मतलब है कि एक कमांड जैसे:

सीडी फू

अकेले आमतौर पर विफल हो जाएगा, क्योंकि पथ पर कोई कमांड `सीडी' नहीं है। लेकिन आदेश
स्ट्रिंग:

सीडी $<:d; टार सीएफ $>:एफ $<:एफ

जब विस्तारित किया जाएगा तब भी शेल मेटा कैरेक्टर सेमी-कोलन होगा, और एक शेल होगा
आदेश की व्याख्या करने के लिए आमंत्रित किया गया। चूँकि 'cd' की व्याख्या इस उप-शेल, कमांड द्वारा की जाती है
अपेक्षानुसार क्रियान्वित होगा।

एकाधिक लक्ष्यों के साथ एक कमांड निर्दिष्ट करने के लिए, आप किसी सूची का संदर्भ निर्दिष्ट कर सकते हैं
लक्ष्य. पर्ल में, किसी सूची को वर्गाकार कोष्ठकों में संलग्न करके एक सूची संदर्भ बनाया जा सकता है।
इसलिए निम्नलिखित आदेश:

कमांड $env ['foo.h', 'foo.c'], 'foo.template', q(
जनन %1
);

ऐसे मामले में इस्तेमाल किया जा सकता है जहां कमांड `जेन' दो फाइलें बनाता है फू.एच और फू.सी.

RSI 'वस्तुएँ' तरीका

'ऑब्जेक्ट्स' विधि निर्दिष्ट के अनुरूप ऑब्जेक्ट फ़ाइलें बनाने की व्यवस्था करती है
स्रोत फ़ाइलें। इसे नीचे दिखाए अनुसार लागू किया गया है:

@फ़ाइलें = ऑब्जेक्ट $env ;

यूनिक्स के अंतर्गत, स्रोत फ़ाइलें समाप्त होती हैं .s और .c वर्तमान में समर्थित हैं, और संकलित किए जाएंगे
उसी फ़ाइल के नाम में जिसके अंत में .o. डिफ़ॉल्ट रूप से, सभी फ़ाइलें इनवोकिंग द्वारा बनाई जाती हैं
बाहरी कमांड जो `CCCOM' निर्माण चर का विस्तार करने के परिणामस्वरूप होता है
`%<' और `%>' क्रमशः स्रोत और ऑब्जेक्ट फ़ाइलों पर सेट होते हैं ('कमांड' विधि देखें)
विस्तार विवरण के लिए)। स्रोत फ़ाइलों को स्कैन करते समय वेरिएबल `CPPPATH' का भी उपयोग किया जाता है
निर्भरता के लिए. यह पथनामों की एक कोलन से अलग की गई सूची है, और इसका उपयोग बनाने के लिए भी किया जाता है
निर्माण चर `_IFLAGS', जिसमें -`I' की उपयुक्त सूची होगी
संकलन के लिए विकल्प. `CPPPATH' में किसी भी सापेक्ष पथनाम की व्याख्या सापेक्ष की जाती है
उस निर्देशिका में जिसमें संबंधित निर्माण वातावरण बनाया गया था (पूर्ण)।
और शीर्ष-सापेक्ष नामों का भी उपयोग किया जा सकता है)। इस वेरिएबल का उपयोग `CCCOM' द्वारा किया जाता है। व्यवहार
इस कमांड को इंटरपोलेटेड किसी भी वेरिएबल को बदलकर संशोधित किया जा सकता है
`CCCOM' में, जैसे `CC', `CFLAGS', और, अप्रत्यक्ष रूप से, `CPPPATH'। यह भी संभव है
`CCCOM' का मान स्वयं बदलें। सुविधा के तौर पर, यह फ़ाइल की सूची लौटाती है
ऑब्जेक्ट फ़ाइल नाम.

RSI `कार्यक्रम' तरीका

'प्रोग्राम' विधि निर्दिष्ट प्रोग्राम को निर्दिष्ट ऑब्जेक्ट से जोड़ने की व्यवस्था करती है
फ़ाइलें. इसे निम्नलिखित तरीके से लागू किया जाता है:

कार्यक्रम $env , ;

प्रोग्राम नाम में `SUFEXE' निर्माण चर का मान जोड़ा जाएगा (द्वारा)।
डिफ़ॉल्ट, Win32 सिस्टम पर `.exe', यूनिक्स सिस्टम पर कुछ भी नहीं) यदि प्रत्यय पहले से नहीं है
वर्तमान।

ऑब्जेक्ट फ़ाइलों के स्थान पर स्रोत फ़ाइलें निर्दिष्ट की जा सकती हैं - 'ऑब्जेक्ट' विधि होगी
सभी फ़ाइलों को ऑब्जेक्ट फ़ाइलों में बदलने की व्यवस्था करने के लिए आह्वान किया गया, और इसलिए सभी
उपरोक्त 'ऑब्जेक्ट्स' विधि के बारे में टिप्पणियाँ इस विधि पर भी लागू होती हैं।

प्रोग्राम की वास्तविक लिंकिंग को एक बाहरी कमांड द्वारा नियंत्रित किया जाएगा जिसके परिणामस्वरूप
`LINKCOM' निर्माण चर का विस्तार करने से, `%<' को ऑब्जेक्ट फ़ाइलों पर सेट करने के साथ
लिंक किया जाए (प्रस्तुत क्रम में), और `%>' लक्ष्य पर सेट करें ('कमांड' विधि देखें)
विस्तार विवरण के लिए)। उपयोगकर्ता निर्माण में अतिरिक्त चर सेट कर सकता है
पर्यावरण, जिसमें `लिंक' भी शामिल है, यह परिभाषित करने के लिए कि लिंकिंग के लिए किस प्रोग्राम का उपयोग करना है, `LIBPATH', ए
लाइब्रेरी विशिष्टताओं के साथ उपयोग के लिए लाइब्रेरी खोज पथों की कोलन-पृथक सूची
प्रपत्र -लिब, और `LIBS', (दोनों में से किसी एक में) लिंक करने के लिए पुस्तकालयों की सूची निर्दिष्ट करता है -लिब
प्रपत्र या केवल पथनाम के रूप में। `LIBPATH' और `LIBS' दोनों में सापेक्ष पथनामों की व्याख्या की गई है
उस निर्देशिका के सापेक्ष जिसमें संबंधित निर्माण वातावरण बनाया गया है
(पूर्ण और शीर्ष-सापेक्ष नामों का भी उपयोग किया जा सकता है)। विपक्ष स्वचालित रूप से सेट हो जाता है
`LIBS' में उल्लिखित किसी भी पुस्तकालय पर निर्भरता: उन पुस्तकालयों का निर्माण पहले किया जाएगा
आदेश लिंक किया गया है.

RSI 'लाइब्रेरी' तरीका

'लाइब्रेरी' विधि निर्दिष्ट ऑब्जेक्ट से निर्दिष्ट लाइब्रेरी बनाने की व्यवस्था करती है
फ़ाइलें. इसे इस प्रकार लागू किया जाता है:

लाइब्रेरी $env , ;

लाइब्रेरी नाम में `SUFLIB' निर्माण चर का मान जोड़ा जाएगा (द्वारा)।
डिफ़ॉल्ट, Win32 सिस्टम पर `.lib', यूनिक्स सिस्टम पर `.a') यदि प्रत्यय पहले से नहीं है
वर्तमान।

ऑब्जेक्ट फ़ाइलों के स्थान पर स्रोत फ़ाइलें निर्दिष्ट की जा सकती हैं - 'ऑब्जेक्ट' विधि होगी
सभी फ़ाइलों को ऑब्जेक्ट फ़ाइलों में बदलने की व्यवस्था करने के लिए आह्वान किया गया, और इसलिए सभी
उपरोक्त 'ऑब्जेक्ट्स' विधि के बारे में टिप्पणियाँ इस विधि पर भी लागू होती हैं।

लाइब्रेरी का वास्तविक निर्माण एक बाहरी कमांड द्वारा नियंत्रित किया जाएगा जिसके परिणामस्वरूप
'ARCOM' निर्माण चर का विस्तार करने से, लाइब्रेरी सदस्यों के लिए '%<' सेट के साथ (in)
प्रस्तुत आदेश), और बनाई जाने वाली लाइब्रेरी के लिए `%>' (इसके लिए `कमांड' विधि देखें
विस्तार विवरण)। उपयोगकर्ता निर्माण परिवेश में वेरिएबल सेट कर सकता है जो ऐसा करेगा
कमांड के संचालन को प्रभावित करें। इनमें `एआर', उपयोग के लिए संग्रह कार्यक्रम शामिल है,
'ARFLAGS', जिसका उपयोग 'AR' द्वारा निर्दिष्ट प्रोग्राम को दिए गए झंडों को संशोधित करने के लिए किया जा सकता है,
और `RANLIB', एक संग्रह सूचकांक पीढ़ी कार्यक्रम का नाम, यदि आवश्यक हो (यदि विशेष हो)।
आवश्यकता को बाद की कार्यक्षमता की आवश्यकता नहीं है, तो 'ARCOM' को फिर से परिभाषित नहीं किया जाना चाहिए
संदर्भ `रानलिब')।

'लाइब्रेरी' विधि एक ही लाइब्रेरी को एकाधिक विधि में निर्दिष्ट करने की अनुमति देती है
मंगलाचरण. सभी आह्वानों से योगदान देने वाली सभी वस्तुएँ (जो कि हो सकती हैं)।
विभिन्न निर्देशिकाएँ) एक एकल संग्रह कमांड द्वारा संयुक्त और उत्पन्न की जाती हैं। टिप्पणी,
हालाँकि, यदि आप किसी बिल्ड की काट-छाँट करते हैं ताकि लाइब्रेरी का केवल एक भाग ही निर्दिष्ट हो, केवल तभी
लाइब्रेरी का वह हिस्सा उत्पन्न हो जाएगा (बाकी गायब हो जाएगा!)।

RSI 'मॉड्यूल' तरीका

'मॉड्यूल' विधि 'प्रोग्राम' और 'कमांड' विधियों का एक संयोजन है। इसके बजाय
सीधे एक निष्पादन योग्य प्रोग्राम उत्पन्न करते हुए, यह कमांड आपको अपना स्वयं का निर्दिष्ट करने की अनुमति देता है
वास्तव में एक मॉड्यूल उत्पन्न करने के लिए कमांड। विधि इस प्रकार लागू की गई है:

मॉड्यूल $env , , ;

यह कमांड ऐसे मामलों में उपयोगी है जहां आप बनाना चाहते हैं, उदाहरण के लिए, गतिशील रूप से
लोड किए गए मॉड्यूल, या स्थिर रूप से जुड़े कोड लाइब्रेरी।

RSI 'निर्भर करता है' तरीका

'निर्भर' विधि आपको किसी लक्ष्य के लिए अतिरिक्त निर्भरताएँ निर्दिष्ट करने की अनुमति देती है। यह है
इस प्रकार आह्वान किया गया:

$env पर निर्भर करता है , ;

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

एकाधिक लक्ष्यों के लिए समान निर्भरता का एक सेट संदर्भ का उपयोग करके निर्दिष्ट किया जा सकता है
लक्ष्यों की एक सूची. पर्ल में, किसी सूची को वर्गाकार में संलग्न करके एक सूची संदर्भ बनाया जा सकता है
कोष्ठक। इसलिए निम्नलिखित आदेश:

निर्भर करता है $env ['foo', 'bar'], 'input_file_1', 'input_file_2';

निर्दिष्ट करता है कि दोनों foo और बार फ़ाइलें सूचीबद्ध इनपुट फ़ाइलों पर निर्भर करती हैं।

RSI 'अनदेखा' तरीका

'अनदेखा' विधि आपको स्पष्ट रूप से उन निर्भरताओं को अनदेखा करने की अनुमति देती है जो विपक्ष इसके बारे में अनुमान लगाता है
अपना। इसे इस प्रकार लागू किया जाता है:

अनदेखा करना ;

इसका उपयोग सिस्टम हेडर फ़ाइलों में परिवर्तन के कारण होने वाले पुनर्संकलन से बचने के लिए किया जा सकता है
उपयोगिताएँ जो उत्पन्न लक्ष्यों को प्रभावित नहीं करने के लिए जानी जाती हैं।

यदि, उदाहरण के लिए, एक प्रोग्राम कई सिस्टमों पर एनएफएस-माउंटेड निर्देशिका में बनाया गया है
की अलग-अलग प्रतियाँ हैं stdio.hमतभेद का असर सभी के हस्ताक्षरों पर पड़ेगा
स्रोत फ़ाइलों से निर्मित व्युत्पन्न लक्ष्य जो `#शामिल हैं '. इससे सभी को परेशानी होगी
सिस्टम बदलते समय उन लक्ष्यों को फिर से बनाया जाना चाहिए। यदि यह वांछनीय व्यवहार नहीं है,
तो निम्न पंक्ति निर्भरता को हटा देगी stdio.h फ़ाइल:

'^/usr/include/stdio\.h$' पर ध्यान न दें;

ध्यान दें कि 'अनदेखा' पद्धति के तर्क नियमित अभिव्यक्ति हैं, इसलिए विशेष हैं
पात्रों से बचना चाहिए और आप शुरुआत या अंत को एंकर करना चाह सकते हैं
`^' या `$' वर्णों के साथ अभिव्यक्ति।

RSI 'नमक' तरीका

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

नमक $स्ट्रिंग;

साल्ट मान बदलने से प्रत्येक व्युत्पन्न फ़ाइल का पूर्ण पुनर्निर्माण बाध्य होगा। यह हो सकता है
कुछ वांछित परिस्थितियों में पुनर्निर्माण के लिए बाध्य करने के लिए उपयोग किया जाता है। उदाहरण के लिए,

नमक `uname -s`;

जब भी ऑपरेटिंग सिस्टम चालू होगा, प्रत्येक व्युत्पन्न फ़ाइल के पूर्ण पुनर्निर्माण को बाध्य करेगा
जो निर्माण किया जाता है (जैसा कि `uname -s' द्वारा रिपोर्ट किया गया है) परिवर्तन।

RSI 'कैश का प्रयोग करें' तरीका

'UseCache' विधि विपक्ष को साझा की जाने वाली व्युत्पन्न फ़ाइलों का कैश बनाए रखने का निर्देश देती है
एक ही परियोजना के अलग-अलग निर्मित पेड़ों के बीच।

कैश का उपयोग करें ("कैश/ ") ⎪⎪ चेतावनी("कैश निर्देशिका नहीं मिली");

RSI 'सोर्सपाथ' तरीका

'सोर्सपाथ' मैथोड फ़ाइल का वास्तविक स्रोत पथ नाम लौटाता है, जैसा कि इसके विपरीत है
बिल्ड निर्देशिका के भीतर पथ का नाम। इसे इस प्रकार लागू किया जाता है:

$पथ = सोर्सपाथ ;

RSI 'कंसपाथ' तरीका

यदि आपूर्ति किया गया पथ एक व्युत्पन्न फ़ाइल है, तो `कॉन्सपाथ' विधि सत्य हो जाती है और वापस आ जाती है
अन्यथा अपरिभाषित (झूठा)। इसे इस प्रकार लागू किया जाता है:

$परिणाम = कंसपाथ ;

RSI 'स्प्लिटपाथ' तरीका

'स्प्लिटपाथ' विधि डिफ़ॉल्ट द्वारा अलग की गई स्ट्रिंग में एकाधिक पथ नामों को ढूंढती है
ऑपरेटिंग सिस्टम के लिए पथ विभाजक (':' UNIX सिस्टम पर, ';' Windows NT पर), और
पूर्णतः योग्य नाम लौटाता है। इसे इस प्रकार लागू किया जाता है:

@पथ = स्प्लिटपाथ ;

'स्प्लिटपाथ' विधि '#' उपसर्ग वाले नामों को उचित शीर्ष-स्तरीय बिल्ड में परिवर्तित कर देगी
नाम ('#' के बिना) और सापेक्ष नामों को शीर्ष-स्तरीय नामों में परिवर्तित कर देगा।

RSI 'दिरपाथ' तरीका

'DirPath' विधि बिल्ड पथ लौटाती है नामकिसी निर्देशिका या निर्देशिकाओं की सूची।
इसे इस प्रकार लागू किया जाता है:

$cwd = DirPath ;

'DirPath' पद्धति का सबसे आम उपयोग है:

$cwd = DirPath '.';

किसी सहायक कंपनी की वर्तमान निर्देशिका का पथ लाने के लिए भरती होनेवाला फ़ाइल.

RSI `फ़ाइलपथ' तरीका

'फ़ाइलपाथ' विधि बिल्ड पथ लौटाती है नामकिसी फ़ाइल या फ़ाइलों की सूची का। यह है
इस प्रकार आह्वान किया गया:

$फ़ाइल =फ़ाइलपाथ ;

RSI 'मदद' तरीका

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

मदद ;

'सहायता' विधि को केवल एक बार कॉल किया जा सकता है, और इसे आम तौर पर शीर्ष में निर्दिष्ट किया जाना चाहिए-
स्तर के निर्माण के फ़ाइल.

विस्तार नुकसान

अधिभावी निर्माण चर

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

जोड़ना नई तरीकों

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

# विपक्ष::इंस्टॉलस्क्रिप्ट - शेल का एक प्लेटफ़ॉर्म पर निर्भर संस्करण बनाएं
स्ट्रिंग ``#!your-path-here'' को प्लेटफ़ॉर्म विशिष्ट से प्रतिस्थापित करके # स्क्रिप्ट
# पथ $BIN_DIR.

उपविपक्ष::इंस्टॉलस्क्रिप्ट {
मेरा ($env, $dst, $src) = @_;
कमांड $env $dst, $src, qq(
sed s+आपका-पथ-यहां+$BIN_DIR+ %< > %>
chmod oug+x %>
);
}

ध्यान दें कि इस विधि को सीधे `cons' पैकेज में परिभाषित किया गया है (नाम उपसर्ग करके)।
`विपक्ष::') के साथ। इस तरीके से किया गया परिवर्तन विश्व स्तर पर सभी परिवेशों में दिखाई देगा,
और इसे निम्नलिखित उदाहरण में कहा जा सकता है:

इंस्टालस्क्रिप्ट $env "$BIN/foo", "foo.tcl";

व्यापकता में एक छोटे से सुधार के लिए, 'बिंदिर' वेरिएबल को एक के रूप में पारित किया जा सकता है
तर्क या निर्माण परिवेश से लिया गया - `%BINDIR' के रूप में।

अधिभावी तरीकों

'विपक्ष' नाम स्थान में विधि जोड़ने के बजाय, आप एक नया पैकेज परिभाषित कर सकते हैं
जो `cons' पैकेज से मौजूदा तरीकों को प्राप्त करता है और दूसरों को ओवरराइड या जोड़ता है। यह
पर्ल के इनहेरिटेंस तंत्र का उपयोग करके किया जा सकता है।

निम्नलिखित उदाहरण एक नए पैकेज `cons::switch' को परिभाषित करता है जो मानक को ओवरराइड करता है
`लाइब्रेरी' विधि. ओवरराइड विधि लाइब्रेरी के बजाय लिंक्ड लाइब्रेरी मॉड्यूल बनाती है
पुरालेख. एक नया कंस्ट्रक्टर प्रदान किया गया है। इस कंस्ट्रक्टर के साथ वातावरण बनाया जाएगा
नई पुस्तकालय पद्धति है; अन्य नहीं करेंगे.

पैकेज विपक्ष::स्विच;
शुरू करें {@ISA = 'cons'}

उप नया {
खिसक जाना;
नए विपक्ष को आशीर्वाद दें (@_);
}

उप पुस्तकालय {
मेरा($env) = शिफ्ट;
मेरा($lib) = शिफ्ट;
मेरा (@objs) = ऑब्जेक्ट $env @_;
कमांड $env $lib, @objs, q(
%LD -r %LDFLAGS %< -o %>
);
}

इस कार्यक्षमता को निम्नलिखित उदाहरण के अनुसार लागू किया जा सकता है:

$env = नया विपक्ष::स्विच(ओवरराइड);
...
लाइब्रेरी $env 'lib.o', 'foo.c', 'bar.c';

लागू नुकसान

'विपक्ष' कमांड आमतौर पर बिल्ड ट्री की जड़ से लागू किया जाता है। ए के निर्माण के पट्टिका
उस निर्देशिका में मौजूद होना चाहिए. यदि `-f' तर्क का उपयोग किया जाता है, तो एक वैकल्पिक के निर्माण के
फ़ाइल का उपयोग किया जा सकता है (और, संभवतः, एक वैकल्पिक रूट, क्योंकि `cons' सीडी होगा के निर्माण के
फ़ाइल की निर्देशिका युक्त)।

यदि '-t' तर्क के साथ बिल्ड ट्री की जड़ के बच्चे से 'cons' का आह्वान किया जाता है, तो यह
की तलाश में निर्देशिका पदानुक्रम पर चलेंगे के निर्माण के फ़ाइल। (एक वैकल्पिक नाम हो सकता है
अभी भी `-f' के साथ निर्दिष्ट किया जाएगा।) कमांड लाइन पर दिए गए लक्ष्य संशोधित किए जाएंगे
खोजे गए के सापेक्ष होना के निर्माण के फ़ाइल। उदाहरण के लिए, किसी निर्देशिका से
एक शीर्ष स्तर के निर्माण के फ़ाइल, निम्नलिखित आह्वान:

% सीडी libfoo/subdir
% विपक्ष -t लक्ष्य

बिल्कुल बराबर है:

% विपक्ष libfoo/subdir/target

यदि निर्देशिका पदानुक्रम में कोई 'डिफ़ॉल्ट' लक्ष्य निर्दिष्ट हैं के निर्माण के or
भरती होनेवाला फ़ाइलें, केवल डिफ़ॉल्ट लक्ष्य उस निर्देशिका पर या नीचे जहां से `cons -t'
का आह्वान किया गया था बनाया जाएगा.

आदेश इस प्रकार लागू किया गया है:

दोष --

जहां तर्क किसी भी क्रम में निम्नलिखित में से कोई भी हो सकता है:

लक्ष्य निर्दिष्ट लक्ष्य बनाएं. अगर लक्ष्य एक निर्देशिका है, फिर पुनरावर्ती रूप से निर्माण करें
उस निर्देशिका के भीतर सब कुछ।

+पैटर्न की सीमा भरती होनेवाला केवल उन्हीं फ़ाइलों पर विचार किया जाता है जो मेल खाती हैं पैटर्नहै, जो है
एक पर्ल नियमित अभिव्यक्ति। एकाधिक `+' तर्क स्वीकार किए जाते हैं।

नाम=
सेट नाम महत्व के लिए लहर 'एआरजी' में हैश शीर्ष स्तर पर पहुंच गया है के निर्माण के फ़ाइल.

`-सीसी' कमांड दिखाएं जो कैश से पुनर्प्राप्त करते समय निष्पादित किया गया होगा। नहीं
संकेत दिया गया है कि फ़ाइल पुनर्प्राप्त कर ली गई है; यह इसके लिए उपयोगी है
बिल्ड लॉग उत्पन्न करना जिनकी तुलना वास्तविक बिल्ड लॉग से की जा सकती है।

`-सीडी' सभी कैशिंग अक्षम करें। कैश से पुनर्प्राप्त न करें और न ही कैश में फ्लश करें।

`-cr' यादृच्छिक क्रम में निर्भरता बनाएँ। एकाधिक निर्माण करते समय यह उपयोगी है
कैशिंग सक्षम के साथ समान पेड़।

`-सीएस' मौजूदा बिल्ड लक्ष्यों को सिंक्रनाइज़ करता है जो कैश के साथ अद्यतित पाए जाते हैं।
यह उपयोगी है यदि कैशिंग को -cc के साथ अक्षम कर दिया गया है या हाल ही में सक्षम किया गया है
यूज़कैश के साथ।

`-d' निर्भरता डिबगिंग सक्षम करें।

`-एफ'
इसके बजाय निर्दिष्ट फ़ाइल का उपयोग करें के निर्माण के (लेकिन पहले युक्ति में बदलें
की निर्देशिका पट्टिका).

`-h' यदि ऐसा कोई परिभाषित किया गया है तो वर्तमान बिल्ड के लिए स्थानीय सहायता संदेश दिखाएं और बाहर निकलें।

`-k' त्रुटियों के बाद जहाँ तक संभव हो आगे बढ़ते रहें।

`-ओ'
ओवरराइड फ़ाइल पढ़ें पट्टिका.

`-पी' निर्दिष्ट पेड़ों में निर्माण उत्पाद दिखाएं। कोई निर्माण का प्रयास नहीं किया गया है.

`-pa' निर्माण उत्पाद और संबंधित क्रियाएं दिखाएं। किसी निर्माण का प्रयास नहीं किया गया है.

`-pw' उत्पाद दिखाएं और उन्हें कहां परिभाषित किया गया है। किसी निर्माण का प्रयास नहीं किया गया है.

`-q' लक्ष्यों को स्थापित करने और हटाने के बारे में अधिक बात न करें।

`-r' से जुड़े निर्माण उत्पादों को हटा दें . किसी निर्माण का प्रयास नहीं किया गया है.

`-आर'
में फ़ाइलें खोजें रेपो. विभिन्न -R रेपो में निर्देशिकाएँ खोजी जाती हैं
आदेश निर्दिष्ट।

`-t' एक की तलाश में निर्देशिका पदानुक्रम को पार करें के निर्माण के फ़ाइल, यदि कोई मौजूद नहीं है
वर्तमान निर्देशिका में. के सापेक्ष लक्ष्यों को संशोधित किया जाएगा
के निर्माण के फ़ाइल.

`-v' `cons' संस्करण दिखाएं और प्रसंस्करण जारी रखें।

`-V' `cons' संस्करण दिखाएं और बाहर निकलें।

`-wf'
विचाराधीन सभी फ़ाइल नाम लिखें पट्टिका.

`-x' इस जैसा एक सहायता संदेश दिखाएं, और बाहर निकलें।

तथा निर्माण-तर्क कोई भी तर्क हो सकता है जिसे आप संसाधित करना चाहते हैं के निर्माण के फ़ाइल.
ध्यान दें कि एक होना चाहिए -- तर्कों को विपक्ष और उन तर्कों को अलग करना जो आप करते हैं
में प्रोसेस करना चाहते हैं के निर्माण के फ़ाइल.

का प्रसंस्करण निर्माण-तर्क जैसे किसी भी मानक पैकेज द्वारा किया जा सकता है गेटोप्ट या उसके
वेरिएंट, या कोई उपयोगकर्ता परिभाषित पैकेज। विपक्ष में पारित हो जाएगा निर्माण-तर्क as @ARGV और
के बाद किसी भी चीज़ की व्याख्या करने का प्रयास नहीं करूंगा --.

% cons -R /usr/local/repository -d os=solaris +driver -- -c test -f DEBUG

विपक्ष को निम्नलिखित पारित करेगा

-R /usr/local/repository -d os=solaris +driver

और निम्नलिखित, शीर्ष स्तर तक के निर्माण के के रूप में दर्ज करें @ARGV

-सी टेस्ट -एफ डीबग

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

विकल्प `-p', `-pa', और `-pw' पढ़ने में सहायता के रूप में उपयोग के लिए बेहद उपयोगी हैं
स्क्रिप्ट या उन्हें डिबग करना। यदि आप जानना चाहते हैं कि कौन सी स्क्रिप्ट इंस्टॉल होती है निर्यात/शामिल/foo.h,
उदाहरण के लिए, बस टाइप करें:

% विपक्ष -pw निर्यात/शामिल/foo.h

का प्रयोग और लिख रहे हैं निर्भरता स्कैनर

क्विकस्कैन स्रोत फ़ाइलों के लिए सरल लक्ष्य-स्वतंत्र स्कैनर स्थापित करने की अनुमति देता है। केवल
एक क्विकस्कैन स्कैनर किसी भी स्रोत फ़ाइल और वातावरण से जुड़ा हो सकता है।

क्विकस्कैन को इस प्रकार लागू किया जाता है:

क्विकस्कैन कॉन्सेनव कोडरफ, फ़ाइलनाम [, पथ]

CodeREF द्वारा संदर्भित सबरूटीन में शामिल फ़ाइल नामों की एक सूची वापस आने की उम्मीद है
सीधे फ़ाइल द्वारा. बदले में, ये फ़ाइल नाम स्कैन किए जाएंगे। वैकल्पिक PATH तर्क
उपयोगकर्ता द्वारा प्रदत्त FILENAME और/या लौटाई गई फ़ाइलों को खोजने के लिए एक लुकअप पथ प्रदान करता है
सबरूटीन. PATH लुकअप-निर्देशिका नामों की एक सरणी का संदर्भ हो सकता है, या a
सिस्टम के विभाजक वर्ण (':' UNIX सिस्टम पर, ';' पर) द्वारा अलग किए गए नामों की स्ट्रिंग
विंडोज़ एनटी)।

फ़ाइल में प्रत्येक पंक्ति के लिए सबरूटीन को एक बार कॉल किया जाता है, $_ को वर्तमान लाइन पर सेट किया जाता है।
यदि सबरूटीन को अतिरिक्त पंक्तियों, या, उस मामले के लिए, संपूर्ण फ़ाइल को देखने की आवश्यकता है,
तो यह उन्हें स्कैन फ़ाइलहैंडल से स्वयं ही पढ़ सकता है। यदि यह लूप को समाप्त भी कर सकता है
यह जानता है कि फ़ाइलहैंडल को बंद करने से आगे कोई भी जानकारी उपलब्ध नहीं है।

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

यहाँ एक वास्तविक उदाहरण है, जो a से लिया गया है के निर्माण के यहां फ़ाइल करें:

उप विपक्ष::एसएमएफजेन {
मेरा($env, @tables) = @_;
foreach $t (@tables) {
$env->QuickScan(sub { /\b\S*?\.smf\b/g }, "$t.smf",
$env->{SMF_INCLUDE_PATH});
$env->कमांड(
["$t.smdb.cc","$t.smdb.h","$t.snmp.cc","$t.ami.cc", "$t.http.cc"],
"$t.smf",
q(
smfgen %( %SMF_INCLUDE_OPT %) %
)
);
}
}

[ध्यान दें कि फॉर्म `$env->QuickScan...' और `$env->Command...' नहीं होना चाहिए
आवश्यक है, लेकिन, किसी कारण से, इस विशेष आह्वान के लिए आवश्यक है। ऐसा प्रतीत होता है
पर्ल में बग होना या मेरी ओर से ग़लतफ़हमी होना; यह मंगलाचरण शैली नहीं है
हमेशा आवश्यक प्रतीत होता है।]

इससे फ़ॉर्म के सभी नाम मिल जाते हैं फ़ाइल में .smf. भले ही यह नाम वापस कर देगा
वे टिप्पणियों में पाए जाते हैं, लेकिन यह ठीक है (तंत्र अतिरिक्त फ़ाइलों को माफ कर रहा है;
उन्हें केवल इस धारणा पर नजरअंदाज कर दिया जाता है कि गुम हुई फ़ाइल पर ध्यान दिया जाएगा जब
प्रोग्राम, इस उदाहरण में, smfgen, वास्तव में लागू किया गया है)।

किसी दिए गए स्रोत फ़ाइल के लिए स्कैनर केवल तभी लागू किया जाता है जब किसी लक्ष्य के लिए इसकी आवश्यकता होती है
पेड़। किसी दिए गए स्रोत फ़ाइल के लिए इसे केवल एक बार ही लागू किया जाता है।

यहाँ उसी स्कैनर को बनाने का एक और तरीका है। यह एक स्पष्ट कोड संदर्भ का उपयोग करता है,
और (अनिवार्य रूप से, इस मामले में) पूरी फ़ाइल को ही पढ़ता है:

उप माइस्कैन {
मेरा (@शामिल);
करना {
पुश (@includes, /\b\S*?\.smf\b/g);
} जबकि ;
@शामिल है
}

ध्यान दें कि लूप का क्रम उल्टा है, लूप परीक्षण अंत में है। यह है
क्योंकि पहली पंक्ति आपके लिए पहले ही पढ़ी जा चुकी है। इस स्कैनर को किसी स्रोत से जोड़ा जा सकता है
फ़ाइल द्वारा:

क्विकस्कैन $env \myscan, "$_.smf";

समर्थन और सुझाव

विपक्ष का रखरखाव उपयोगकर्ता समुदाय द्वारा किया जाता है। सदस्यता लेने के लिए मेल भेजें विपक्ष-चर्चा-
[ईमेल संरक्षित] शरीर के साथ सदस्यता के.

कृपया किसी भी सुझाव के माध्यम से रिपोर्ट करें [ईमेल संरक्षित] मेलिंग सूची

onworks.net सेवाओं का उपयोग करके ऑनलाइन विपक्ष का उपयोग करें