makepp_incompatibilities - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

makepp_incompatibilities -- makepp और GNU के बीच असंगति

वर्णन

Makepp को GNU के यथासंभव निकट होने के लिए डिज़ाइन किया गया था
(<http://www.gnu.org/software/make/manual/make.html>)। जीएनयू ऑटोटूल
(<http://www.gnu.org/software/automake/manual/automake.html>), सीएमके
(<http://www.cmake.org/>), प्रेमेक (http://industriousone.com/premake> और टिप्पणी देखें
नीचे) या दस्तकारी विरासत निर्माण प्रणालियों को मेकप के साथ निर्माण योग्य होना चाहिए। ये ऐसा है कि
आप या तो परियोजनाओं को सहजता से माइग्रेट कर सकते हैं। या यदि आप सभी का आनंद नहीं लेना चाहते हैं
मेकप के फायदे (उदाहरण के लिए अन्य लोग अभी भी जीएनयू मेक के साथ आपकी परियोजना का निर्माण कर सकते हैं) जबकि आप
आपके विकास के लिए विश्वसनीयता लाभ से लाभ।

हालाँकि, दर्शनशास्त्र में अंतर के कारण, GNU के कुछ मेक या पॉज़िक्स मेक
(<http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html>) सुविधाएँ नहीं हो सकतीं
का समर्थन किया। कुछ को लागू नहीं किया गया है क्योंकि हमारे पास समय नहीं है। के सबसे
जीएनयू मेक से मतभेद काफी तकनीकी हैं और शायद ही कभी समस्याएं पैदा करते हैं। काश
पारंपरिक मेक की कमियों के लिए समाधान अधिक से अधिक जटिल होते जा रहे हैं,
और Makepp को कठिन समय दे रहे हैं।

संक्षेप में, यदि यह बॉक्स से बाहर नहीं बनता है, तो कोशिश करें:

मेकप --नो-चेतावनी
--बिल्ड-चेक=target_newer --अंतिम-मौका-नियम --नो-रीमेक-मेकफ़ाइल्स

यदि वह सफल होता है, तो आप उन तर्कों को एक-एक करके समाप्त करने का प्रयास कर सकते हैं। लेकिन अगर यह विफल हो जाता है,
जोड़ने का प्रयास करें:

--पारंपरिक-पुनरावर्ती-मेक

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

जबरदस्ती अधिक POSIX or जीएनयू बनाना अनुकूलता

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

अनुकूलता के माध्यम से la विकल्प: "--बिल्ड-चेक = target_newer"
डिफ़ॉल्ट रूप से, यदि कोई निर्भरता है, तो मेकप सभी लक्ष्यों को फिर से बनाने का प्रयास करेगा
पिछले निर्माण के बाद से बदल गया है, या यदि आदेश बदल गया है (देखें makepp_build_check for
विवरण)। यह सामान्य रूप से आप क्या चाहते हैं। कभी-कभी, हालांकि, आप लक्ष्य नहीं चाहते हैं
पुनर्निर्माण के लिए अगर इसे मेकप के नियंत्रण के अलावा संशोधित किया गया है (उदाहरण के लिए, संपादन करके
यह, या फ़ाइल बनाने के लिए मैन्युअल रूप से प्रोग्राम चलाकर)। आप Makepp को उपयोग करने के लिए बाध्य कर सकते हैं
पारंपरिक मेक एल्गोरिथम, जो केवल तभी पुनर्निर्माण करता है जब कोई लक्ष्य से नया हो
निर्भरताएँ, इस विकल्प को कमांड लाइन में जोड़कर।

अनुकूलता के माध्यम से la विकल्प: "--dont-build=config.status"
ऐसे पैकेज हैं जो स्वयं को स्वतः कॉन्फ़िगर करने का प्रयास करते हैं, या अन्य कार्य करते हैं, जो gmake
जब तक पूछा नहीं जाता तब तक अनदेखा करता है, जैसे:

config.status : कॉन्फ़िगर करें
./config.status--पुनः जांचें

कॉन्फ़िगर करें: config.in aclocal.m4
autoconf

अधिकांश लोगों के पास "ऑटोकॉन्फ़" भी स्थापित नहीं है, इसलिए ईमानदारी से सब कुछ कर रहे हैं
नियम, जैसा कि मेकप करता है, विफल हो जाएगा। यह विकल्प रोकता है कि, यदि आप समझते हैं कि क्या
निर्माण करने के लिए नहीं।

अनुकूलता के माध्यम से la विकल्प: "--अंतिम-मौका-नियम"
डिफ़ॉल्ट नियम (बिना पैटर्न निर्भरता वाले पैटर्न नियम) सामान्य रूप से समर्थित नहीं होते हैं।
Makepp मौजूदा फाइलों के आधार पर सभी नियमों को तत्काल बनाता है, ताकि वह प्रत्येक के बारे में जागरूक हो
फ़ाइल जो उत्पन्न की जा सकती है। हां इस तरह यह नहीं जानता कि पैटर्न को तुरंत कैसे चालू किया जाए
बिना पैटर्न निर्भरता के नियम। :last_chance तंत्र आंशिक रूप से इसका समाधान करता है।
जहां यह लीगेसी मेकफ़ाइल्स के लिए पर्याप्त है, यह विकल्प इसे विश्व स्तर पर चालू करने की अनुमति देता है।

अनुकूलता के माध्यम से la विकल्प: "--नहीं-चेतावनी"
यह परिणाम में सुधार नहीं करता है। Makepp देगा कई चीजों के लिए चेतावनी संदेश
जिसे पारंपरिक यूनिक्स बिना झिझक के स्वीकार करता है। ऐसा इसलिए है क्योंकि वहाँ हैं
मेकप के साथ उन्हें करने के बेहतर तरीके। अगर ये चेतावनियां आपको परेशान करती हैं, तो आप इन्हें बंद कर सकते हैं
इस विकल्प के साथ।

अनुकूलता के माध्यम से la विकल्प: "--हाइब्रिड-पुनरावर्ती-मेक"
मेक के रिकर्सिव इनवोकेशन को अक्सर एक असुरक्षित अभ्यास माना जाता है (देखें "बेहतर .)
पदानुक्रमित बिल्ड के लिए सिस्टम" विवरण के लिए मेकप में), लेकिन वे बेहद सामान्य हैं
मौजूदा मेकफ़ाइल। Makepp पिछड़े संगतता के लिए पुनरावर्ती मेक का समर्थन करता है; नए के लिए
मेकफ़ाइल, "load_makefile" कथन, या मेकप के निहित का उपयोग करना बेहतर है
मेकफ़ाइल लोडिंग तंत्र।

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

यह ज्यादातर मामलों में काम करता है, लेकिन हो सकता है कि आप उसी से कई मेकफाइल्स को इनवाइट न करें
निर्देशिका, उदाहरण के लिए, निम्नलिखित काम नहीं करेगा:

लक्ष्य: निर्भरता
$(मेक) -f अन्य_मेकफाइल लक्ष्य

इस मामले में मेकप नोटिस करता है कि यह दूसरा मेकफ़ाइल लोड कर रहा है और शिकायत करता है। इस विकल्प के साथ
इसके बजाय यह अतिरिक्त मेकफ़ाइल से निर्माण के पारंपरिक तरीके पर वापस आ जाएगा
प्रत्येक एक अलग मेकप प्रक्रिया।

नोट: तकनीकी रूप से कई मेकफ़ाइल लोड करना कोई समस्या नहीं होगी, लेकिन उनके पास आमतौर पर होता है
एक ही नकली लक्ष्य नाम। इसे अलग रखने का मतलब होगा Makepp का पूरा नया स्वरूप
आंतरिक। हालांकि, यह काम करेगा, लेकिन यह समकक्ष नहीं है:

लक्ष्य: निर्भरता
सीडी उपदिर && $(मेक) -f अन्य_मेकफाइल लक्ष्य

अनुकूलता के माध्यम से la विकल्प: "--पारंपरिक-पुनरावर्ती-मेक"
कभी-कभी पिछला विकल्प पर्याप्त नहीं होता है, खासकर यदि पुनरावर्ती कॉल का उपयोग किया जाता है
विरोधाभासी विकल्प। Makepp वैश्विक विकल्पों के केवल एक सेट का उपयोग करता है, इसलिए एक सबमेक नहीं है
उन्हें संशोधित करने की अनुमति है, क्योंकि यह अन्य मेकफ़ाइल्स से भी संबंधित होगा।

इस विकल्प को कमांड लाइन में जोड़ने से निम्नलिखित अवांछनीय दुष्प्रभाव होते हैं:

पुनरावर्ती बनाता है आंतरिक रूप से समानांतर में निष्पादित नहीं होता है, भले ही माता-पिता करता हो।
जीएमके के विपरीत प्रक्रियाओं की संख्या का कोई समग्र समन्वय नहीं है। यह करेगा
लागू नहीं किया जाएगा क्योंकि काम करने का यह तरीका मेकप का डिज़ाइन लक्ष्य नहीं है।

· रिकर्सिव मेक प्रोसेस को रिपॉजिटरी के बारे में कुछ भी पता नहीं होता है।

· प्रत्येक पुनरावर्ती प्रक्रिया अपनी स्वयं की लॉग फ़ाइल उत्पन्न करती है, जिस निर्देशिका में इसे बुलाया जाता है
में, संपूर्ण बिल्ड के लिए एक लॉग फ़ाइल बनाने के बजाय।

· चूंकि मेकप आमतौर पर पारंपरिक मेक डीम्स से अधिक आवश्यक बनाता है, और चूंकि कई
बिल्ड सिस्टम सभी दिशाओं में पुनरावर्ती कॉल प्रदान करता है, इससे अंतहीन हो सकता है
पुनरावर्तन 50 राउंड के बाद Makepp ब्रेक खींचेगा और आपको बताएगा कि कैसे बढ़ाना है
कि, यदि आपके पास वास्तव में इतना गहरा घोंसला है।

यहां तक ​​​​कि "--पारंपरिक-पुनरावर्ती-मेक" विकल्प के साथ, पर्यावरण चर
"MAKEOVERRIDES" और "MFLAGS" को सेट नहीं किया गया है, और अनदेखा किया गया है, इसलिए मेकफ़ाइल्स जो निर्भर करती हैं
वे काम नहीं करेंगे।

A प्रेमक उत्पन्न makefile उसी में एक उप-आमंत्रण के लिए केवल एक अजीब आवरण है
निर्देशिका। यदि आपके पास कोई परियोजना लक्ष्य है एक्सवायजेड इसकी एक लाइन होगी

@${MAKE} --no-print-directory -C । -एफ एक्सवाईजेड.मेक

इस मामले में आप सीधे आह्वान करके "--पारंपरिक-पुनरावर्ती-मेक" विकल्प से बच सकते हैं
उस के साथ मेकप "-f XYZ.मेक" विकल्प.

अनुकूलता बिना la विकल्प: "--नौकरियां=n"
लिगेसी मेकफ़ाइल्स कभी-कभी सभी निर्भरताओं को सूचीबद्ध नहीं करतीं, जो कि . के क्रम पर निर्भर करती हैं
उन्हें समय पर बनाने के लिए निष्पादन। इस स्थिति में मेकप पहले एक नियम को कॉल करने का प्रबंधन कर सकता है
इसकी निर्भरता सभी बना दी गई है। तब परिणाम कम के साथ बेहतर हो सकते हैं, या नहीं भी
समानांतर निष्पादन।

अनुकूलता के माध्यम से la चर: "मेकप्प_सरल_कॉन्सटेनेशन = 1"
आरसी-शैली प्रतिस्थापन डिफ़ॉल्ट तरीका है मेकप टेक्स्ट में परिवर्तनीय प्रतिस्थापन करता है
तार क्योंकि यह बहुत ही कम विरासत मेकफ़ाइल को तोड़ता है और अक्सर नए में उपयोगी होता है
मेकफ़ाइल्स हालाँकि, यह के प्रतिस्थापन में सामयिक असंगति का परिचय देता है
चर रिक्त स्थान से घिरे नहीं हैं। उदाहरण के लिए,

INCLUDE_PREFIX:= -I/some/include/dir -I
शामिल हैं:= $(INCLUDE_PREFIX)/अन्य/शामिल/दिर

"INCLUDES" को "-I/some/include/dir/other/include/dir -I/other/include/dir" पर सेट करेगा यदि rc-
शैली प्रतिस्थापन सक्षम है, जबकि GNU मेक इसे इस पर सेट करेगा
"-I/some/include/dir -I/other/include/dir"। उदाहरण के लिए, रेडिस 2.6.5 को संकलित करते समय यह करने की कोशिश करता है
"प्रिंटफजीसीसी" चलाएं। दो आदेशों का ऐसा अजीब संयोजन एक मजबूत संकेत है कि
शब्दार्थ बनाने के लिए वापस आने के लिए इस चर की आवश्यकता है।

एक वेरिएबल में व्हॉट्सएप को संभालने में भी एक असंगति है:

शून्य:=
T := -o $(null) # T में -o के बाद एक स्पेस होता है।
आउटफाइल = $ (टी) आउटफाइल

यदि आरसी-शैली प्रतिस्थापन सक्षम है, तो "आउटफाइल" को "-आउटफाइल" पर सेट कर देगा, जबकि जीएनयू मेक
इसे "-o आउटफाइल" पर सेट कर देगा।

इन दोनों असंगतियों को "makepp_simple_concatenation" सेट करके हटा दिया जाता है
चर। हालाँकि, ध्यान दें कि "makepp_simple_concatenation" के साथ भी, makepp अभी भी
कुछ स्थितियों में व्हॉट्सएप के साथ असंगत व्यवहार करता है:

T:= -o # इस कमेंट को डिलीट न करें।

जीएनयू सेट "टी" को "-ओ" रखने के लिए सेट करता है, उसके बाद एक स्पेस होता है, जबकि मेकप स्ट्रिप आउट करता है
वैसे भी पीछे की जगह। यदि आप पिछली जगह चाहते हैं, तो आपको सेट करना होगा
"makepp_simple_concatenation" और डमी वाली तकनीक का उपयोग करके "T" भी ​​सेट करें
चर जैसे "शून्य", जैसा कि ऊपर दिखाया गया है।

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

अनुकूलता के माध्यम से la चर: "मेकप्प_परसेंट_उपदिर = 1"
डिफ़ॉल्ट रूप से, पैटर्न नियम में "%" निर्देशिकाओं से मेल नहीं खाता है। इसका मतलब है कि एक नियम की तरह
इस:

%.ओ: %.सी
$(CC) $(CFLAGS) -c $(इनपुट) -o $(आउटपुट)

"../shared/xyz.c" जैसी फाइलों पर लागू नहीं होगा। यदि आप चाहते हैं कि यह फाइलों से मेल खाए
उपनिर्देशिकाएँ भी, फिर कमांड लाइन पर चर "makepp_percent_subdirs=1" सेट करें
या मेकफ़ाइल की शुरुआत के करीब।

अनुकूलता के माध्यम से la वातावरण चर: $MAKEPP_IGNORE_OPTS
कभी-कभी विरासत पुनरावर्ती आमंत्रण उन विकल्पों को पास करते हैं जो मेकप समझ में नहीं आता है।
उम्मीद है कि विकल्प महत्वपूर्ण नहीं है, लेकिन यह मेकप को चलने से रोकता है। इसके साथ ही
पर्यावरण चर आप मेकप को कुछ विकल्पों को चुपचाप अनदेखा करने के लिए कह सकते हैं। महत्व
विकल्पों की एक स्थान से अलग की गई सूची होगी, जो 4 प्रकारों में आ सकती है:

--लंबा=x
एक लंबा विकल्प जो तर्क की अपेक्षा करता है। इस तथ्य को बराबर के माध्यम से घोषित किया जाना चाहिए
साइन करें, हालांकि वास्तविक उपयोग को व्हाइटस्पेस द्वारा भी अलग किया जा सकता है, या तो "--long=bla" या
"--लॉन्ग ब्ला"।

--लंबा
बिना तर्क के एक लंबा विकल्प।

-sx एक छोटा विकल्प जो तर्क की अपेक्षा करता है। इस तथ्य को जोड़कर घोषित किया जाना चाहिए
विकल्प के ठीक बाद कुछ, हालांकि वास्तविक उपयोग भी अलग हो सकता है
व्हाइटस्पेस, या तो "-sbla" या "-s bla"।

-s तर्क के बिना एक छोटा विकल्प।

उदाहरण के लिए बिना किसी तर्क के Makepp's -R विकल्प को एक-एक करके ओवरराइड करें और gmake के डिबग को स्वीकार करें
तर्क के साथ विकल्प:

निर्यात MAKEPP_IGNORE_OPTS='-R --debug=x'

असंगतियां कि की आवश्यकता होती है makefile परिवर्तन

मेकफाइल्स जो स्पष्ट रूप से मेक को कॉल करते हैं, मेकप को सब कुछ खुद बनाने से रोकते हैं।
अलास पर्ल का अपना "ExtUtils::MakeMaker" निम्नलिखित दो रूपों में से दूसरा रूप देता है
संस्करण 6.56 (पर्ल 5.12.1) तक यह गलती:

उपदिर:
सीडी उपदिर; बनाना

बनाना = बनाना

· "VPATH" वैरिएबल को कुछ वैल्यू पर सेट करना परोक्ष रूप से "vpath % value" को कॉल करता है। "वपथ"
बयानों को भंडार तंत्र के साथ अनुकरण किया जाता है। तो, जहां gmake विकल्प
vpath में मिली फ़ाइल का पथ, makepp इसके बजाय इसे प्रतीकात्मक रूप से लिंक करेगा
जहां इसकी जरूरत है। इस प्रकार मेकप एक असंशोधित स्ट्रिंग प्रदान करेगा, जो आमतौर पर है
एक समस्या नहीं है।

vpath में लक्ष्य समर्थित नहीं हैं। (जीमेक उन्हें मानता है अगर वे इससे नए हैं
उनकी निर्भरता, लेकिन यदि नहीं, तो लक्ष्य को वर्तमान निर्देशिका में फिर से बनाया जाएगा
-- बल्कि असंगत।) vpaths को अनसेट करना समर्थित नहीं है।

मेकफ़ाइल में बाद में मौजूद एक पैटर्न नियम पहले मौजूद एक को ओवरराइड करता है।
यह जीएनयू मेक से पीछे की ओर है।

· अंतर्निहित निहित नियमों का सेट जीएनयू बनाने के नियमों से कुछ अलग है,
हालांकि परिवर्तनीय नाम काफी हद तक संगत हैं। बिल्टिन नियम चाहिए
सफलतापूर्वक सी/सी++/फोरट्रान प्रोग्राम संकलित करें, और वास्तव में अनुमान लगाने में सक्षम हो सकते हैं
कुछ मामलों में उचित पुस्तकालय भी। मोडुला -2 और रैटफॉर और अन्य दुर्लभ के लिए समर्थन
भाषाएं जानबूझकर मौजूद नहीं हैं, क्योंकि मैं जीएनयू के साथ समस्याओं में भागता रहा
मेक के नियम जब मैंने गलती से उन भाषाओं के एक्सटेंशन का पुन: उपयोग किया।

· "+" के एक क्रिया उपसर्ग को चुपचाप अनदेखा कर दिया जाता है।

· संग्रह सदस्य समर्थित नहीं हैं, और न ही संबद्ध स्वचालित चर हैं
$%, "$(%D)", और "$(%F)"।

· कोई एससीसीएस समर्थन नहीं है।

· परिवर्तनीय असाइनमेंट में अग्रणी और अनुगामी व्हॉट्सएप को अनदेखा किया जाता है (भले ही
व्हॉट्सएप के बाद एक टिप्पणी आती है)। व्हॉट्सएप हैंडलिंग के बारे में अधिक जानकारी के लिए
असंगतताएं, makepp_variables में "चर में व्हाइटस्पेस" देखें।

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

· "SHELL" चर को वर्तमान में आंशिक रूप से अनदेखा किया गया है। मेकप हमेशा उपयोग करता है / बिन / श
जब तक /usr/xpg4/bin/sh or /sbin/xpg4/sh पाया जाता है या जब तक आप "SHELL" निर्यात नहीं करते हैं
आपके मेकफ़ाइल में परिवर्तनीय। लेकिन अगर आप करते हैं, तो कमांड पार्सर पूरी तरह से नहीं हो सकता है
समझें कि आपका शेल कमांड क्या करता है। विंडोज स्ट्रॉबेरी या एक्टिवस्टेट पर्ल पर
आपको इसके बजाय अपना SHELL वैरिएबल सेट करना होगा से पहले कॉलिंग मेकप।

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

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

· समर्थित एकमात्र विशेष लक्ष्य ".PHONY" और आंशिक रूप से ".SUFFIXES" है। NS
शेष बस अंतर्निर्मित हैं।

विशेष रूप से, जीएनयू मेक में निम्नलिखित विशेष लक्ष्य हैं:

प्रत्यय
Makepp ".SUFFIXES" को ".SUFFIXES" के विशेष मामले को छोड़कर no . के साथ अनदेखा करता है
निर्भरता, इस तरह:

प्रत्यय:

जो इसे अपने किसी भी डिफ़ॉल्ट नियम को लोड नहीं करने के लिए कहता है।

.इंटरमीडिएट, .सेकंडरी, .PRECIOUS
मध्यवर्ती फाइलों को कोई विशेष दर्जा नहीं दिया गया है और इसलिए ये लक्ष्य नहीं हैं
अर्थपूर्ण।

।अनदेखा करना
इस लक्ष्य की अनदेखी की जाती है। यदि आप त्रुटियों को अनदेखा करना चाहते हैं, तो "ignore_error" शब्द डालें
(या माइनस साइन) कमांड के सामने जिसकी एग्जिट स्टेटस को नजरअंदाज करना है।

मौन
इस लक्ष्य की अनदेखी की जाती है। यदि आप चाहते हैं कि आदेश प्रतिध्वनित न हों, तो "noecho" शब्द डालें
(या "@" वर्ण) उस आदेश के सामने जो प्रतिध्वनित नहीं होना चाहिए,
या मेकप करने के लिए "--silent" विकल्प का उपयोग करें।

.DELETE_ON_ERROR
.EXPORT_ALL_VARIABLES
नोएक्सपोर्ट
पॉज़िक्स
।चूक जाना
ये लक्ष्य समर्थित नहीं हैं और इन्हें केवल अनदेखा किया जाता है।

· GNU मेक फंक्शन "eval", "फ्लेवर" और "वैल्यू" वर्तमान में समर्थित नहीं हैं। आप
"$[...]" के साथ अधिक सीधे-सीधे तरीके से eval जैसी ही चीज़ हासिल कर सकते हैं
चर या कार्य विस्तार।

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

ए :: बी
&बिल्ली बी -ओए

# बाद में आपके मेकफ़ाइल में:
एसी
&cat c -o >>a

यह ठीक ठीक वैसे ही जैसे आपने लिखा था

ए: बीसी
&बिल्ली बी -ओए
&cat c -o >>a

यह निश्चित रूप से डबल कोलन नियमों के लिए नहीं है, और यह हमेशा नहीं होगा
काम करता है, लेकिन यह "स्वच्छ" जैसे लक्ष्यों के लिए या उन सभी चीजों के लिए काम करता है जो
ExtUtils::MakeMaker अपनी मेकफ़ाइल्स में डालता है। किसी और चीज के लिए उस पर भरोसा न करें
विरासत मेकफ़ाइल की तुलना में।

· "$(वाइल्डकार्ड)" फ़ंक्शन न केवल मौजूद फाइलों से मेल खाता है, बल्कि फाइलों से भी मेल खाता है
अभी तक अस्तित्व में नहीं है, लेकिन जिनके पास एक नियम है जिसे मेकप ने उस समय देखा है
"$(वाइल्डकार्ड)" फ़ंक्शन का मूल्यांकन किया जाता है।

· "परिभाषित" कथन समर्थित है, लेकिन इससे पहले "@" का संचालन किया जाता है
अलग ढंग से। वर्तमान में मेकप में, "@" एक चर के सामने है जिसमें एक बहु-पंक्ति है
मान केवल पहली पंक्ति की प्रतिध्वनि को दबा देगा। उदाहरण के लिए,

इको-लाइनों को परिभाषित करें
&echo लाइन1 -ओ $@
&गूंज लाइन2 -ओ>>$@
एंडीफ

x:
@$(इको-लाइन्स)

"&echo line2" की छपाई को नहीं दबाएगा जैसा कि GNU मेक में करता है; यह केवल
"&echo लाइन1" की छपाई को दबाएं।

मेकप निम्नलिखित पर्यावरण चर का समर्थन नहीं करता है (यह उन्हें सेट नहीं करता है,
और यह सिर्फ उन्हें अनदेखा करता है):

बदलाव
एमएफएलएजीएस

असंगतियां in आदेश of अभिव्यक्ति विस्तार
मेकप में, सभी निर्भरताओं की गारंटी होने से पहले नियम क्रियाओं का विस्तार किया जाता है
निर्मित किया गया है। आप इस तरह के नियमों को बदलकर इसके आसपास काम कर सकते हैं:

फू: बार
जेनफू <$(शेल कैट बार)

इसके लिए:

फू: बार
जेनफू <`कैट बार`

या यह, जो विस्तार के दौरान फ़ाइल बना देगा:

फू: बार
जेनफू <$(&बिल्ली $(बार बनाएं))

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

· हालांकि मैंने इसे इस्तेमाल होते नहीं देखा है, जीएनयू मेक निम्नलिखित की अनुमति देता है:

कोलन = :
a$(बृहदान्त्र) b
गूंज $^

Makepp इसके काम करने के लिए "$(colon)" को बहुत देर से फैलाता है। हालाँकि यह प्रदान करता है
वैकल्पिक "$[colon]" सिंटैक्स, जो GNU मेक की तुलना में बहुत अधिक कर सकता है, क्योंकि यह है
बहुत जल्दी विस्तार किया।

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

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

कोष्टक or ब्रेसिज़ नहीं है घोंसला
Makepp पहले मिलान करने वाले कोष्ठक या ब्रेस पर भाव समाप्त करता है। इसके अलावा

$(somefunction ... ( ) ...) # GNU मेक स्टाइल

आपको इनमें से किसी एक का उपयोग करना चाहिए

${somefunction ... ( ) ...} # GNU संगत बनाते हैं
$((somefunction ... ( ) ...)) # Makepp एक्सटेंशन

यह शायद वैकल्पिक रूप से संस्करण 2.1 में तय किया जाएगा।

नाबालिग अंक
पैटर्न निर्भरता नकली लक्ष्यों से मेल नहीं खाती
%.ए:%.बी; ...
$ (फोनी एक्सबी): ; ... # xa . बनाने का कोई तरीका प्रदान नहीं करता है

टिप्पणियों में निरंतरता रेखाएं नहीं होतीं
# यह है \
2-पंक्ति टिप्पणी नहीं

आदेश line असंगतियां

Makepp कुछ अधिक उपयोगी कमांड लाइन विकल्पों का समर्थन करता है। निम्नलिखित, हालांकि,
समर्थित नहीं हैं:

-डी या --डीबग
-एफ -
Makepp के आंतरिक मेकफ़ाइल ऑब्जेक्ट फ़ाइल ऑब्जेक्ट से जुड़े हुए हैं, इसलिए यह संभाल नहीं सकता
स्टडिन

-i
-एल या --लोड-औसत या --मैक्स-लोड
-एम मेकप के "-एम" विकल्प का संबंध सिग्नेचर मेथड सिलेक्शन से है, जबकि जीएनयू मेक
उपेक्षा - एम।

-पी या --प्रिंट-डेटा-बेस
-क्यू या - प्रश्न
-आर या --नो-बिलिन-वेरिएबल
Makepp का "-R" विकल्प वास्तव में कुछ पूरी तरह से अलग करता है।

-एस --नो-कीप-गोइंग या --स्टॉप
सभी नियमों को सीखने के बाद "--stop" विकल्प बंद हो जाता है (सो जाता है) मेकप, तो आप
संपादन जारी रख सकते हैं।

-टी या --टच
-w या --प्रिंट-निर्देशिका
यह स्वचालित रूप से होता है।

--चेतावनी-अपरिभाषित-चर

इनमें से कुछ को आसानी से समर्थन दिया जा सकता है यदि कोई परवाह करता है।

परिवर्तनीय असंगतियां

Makepp "$(CC)" या . जैसे चर के लिए लौटने के लिए मिलान करने वाले कमांड के लिए $PATH में दिखता है
"$(CXX)", जबकि GNU मेक में स्टैटिक डिफॉल्ट हैं। इसके अलावा मेकप "जीसीसी" को वरीयता देता है और
"जी ++" जबकि आश्चर्यजनक रूप से जीएनयू पूर्व के लिए "सीसी" रिटर्न देता है, लेकिन वही
बाद वाला। आप इन्हें मेकफ़ाइल में, कमांड लाइन पर या निर्यात करके ओवरराइड कर सकते हैं a
मेकप को लागू करने से पहले एक ही नाम का चर।

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