Red Hat के एक कर्मचारी ने गोल्स असेंबली सिस्टम प्रस्तुत किया। जीएनयू मेक 4.2 का विमोचन

रिचर्ड डब्लूएम जोन्स, लेखक कामेच्छा, Red Hat में कार्यरत, प्रस्तुत नई असेंबली उपयोगिता लक्ष्यों, जिसका उद्देश्य स्क्रिप्ट की समग्र सरलता और समझ को बनाए रखते हुए मेक की उपयोगिता में कमियों और समस्याओं को दूर करना है। मेक यूटिलिटी को 1976 में डिज़ाइन किया गया था और इसमें सामान्य अवधारणा को बदले बिना इन कमियों को खत्म करने की कई वैचारिक कमियाँ हैं;
लक्ष्य स्रोत कोड द्वारा वितरित GPLv2+ के अंतर्गत लाइसेंस प्राप्त।

समस्याओं का समाधान किया जाना है:

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

• असेंबली निर्देशों के लिए केवल एक पैरामीटर प्रदान करने में समस्या।
  

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

  

• शेल दुभाषिया के साथ बातचीत करने में समस्याएँ। उदाहरण के लिए, फ़ाइल और निर्देशिका नामों में रिक्त स्थान के भागने को नियंत्रित करने की आवश्यकता, प्रत्येक कमांड को निष्पादित करते समय एक अलग शेल दुभाषिया लॉन्च करने पर संसाधनों की बर्बादी, "$" वर्ण की दोहरी व्याख्या (शेल और मेक दोनों में प्रयुक्त), इंडेंटेशन को ध्यान में रखते हुए।

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

  यह था:
  लक्ष्य: foo.o bar.o
  ${CC} ${CFLAGS} $< -o $@

  यह बन गया:
  "लक्ष्य": "foo.o", "bar.o" {
  %CC %CFLAGS %< -o %@
  }

लक्ष्य की अन्य विशेषताएं:

• मनमाने नाम और पैरामीटर निर्दिष्ट करने के लिए वैकल्पिक समर्थन:

  लक्ष्य सभी = : "लक्ष्य"

  लक्ष्य लिंक =
  "लक्ष्य": "foo.o", "bar.o" {... }

  लक्ष्य संकलन (नाम) =
  "%name.o" : "%name.c", "dep.h" { %CC %CFLAGS -c $^ -o $@ }

• दो लॉन्च मोड: फ़ाइल नामों के साथ बिल्ड लक्ष्यों का मिलान करने के लिए मेक मोड (उदाहरण के लिए, फ़ाइल "foo.o" लक्ष्य "%name.o" से मेल खाता है), और प्रत्यक्ष संकलन मोड:

  लक्ष्य सभी = : लिंक

  लक्ष्य लिंक =
  "लक्ष्य" : "foo.o", संकलित करें ("बार") { ... }

  लक्ष्य संकलन (नाम) =
  "%name.o" : "%name.c", "dep.h" { %CC %CFLAGS -c $^ -o $@ }

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

  "लक्ष्य": "foo.o", "bar.o" {... }

  *फ़ाइल("लक्ष्य") : *फ़ाइल("foo.o"), *फ़ाइल("bar.o") { ... }

• डेवलपर असेंबली रणनीति की मनमानी विशेषताओं को परिभाषित कर सकता है। "*फ़ाइल" ध्वज को डिफ़ॉल्ट रूप से परिभाषित किया गया है (@{...} आउटपुट के दमन को इंगित करता है, और "निकास 99" पुनर्निर्माण की आवश्यकता को इंगित करता है):

  युक्ति *फ़ाइल (फ़ाइल नाम) = @{
  परीक्षण -f %फ़ाइलनाम || बाहर निकलें 99
  % में एफ के लिए

  स्रोत: opennet.ru