तो फिर भी, आपको बनाने की आवश्यकता क्यों है?

यह सब शुरू हो गया, ऐसा प्रतीत होता है, एक साधारण प्रश्न के साथ जिसने मुझे पहले स्तूप में ले जाया - "मुझे बनाने की आवश्यकता क्यों है? मुझे बैश स्क्रिप्ट के साथ क्यों नहीं मिल सकता है?"। और मैंने सोचा - वास्तव में, मुझे बनाने की आवश्यकता क्यों है? (और सबसे महत्वपूर्ण) वह किन समस्याओं का समाधान करता है?

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

इसे संकलित करने के लिए, बस एक कमांड चलाएं:

$ gcc main.c -o main 

यह बहुत सरल था। लेकिन कुछ समय बीत जाता है, परियोजना विकसित होती है, कुछ मॉड्यूल इसमें दिखाई देते हैं और स्रोत फाइलें बड़ी हो जाती हैं।

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

 $ gcc -c src0.c $ gcc -c src1.c $ gcc -c main.c $ gcc -o main main.o src0.o src1.o 

सहमत, यह एक लंबी और श्रमसाध्य प्रक्रिया है। ऐसा मैन्युअल रूप से करने के लिए, मैं नहीं करूंगा। मुझे लगता है कि इस प्रक्रिया को केवल एक build.sh स्क्रिप्ट बनाकर स्वचालित किया जा सकता है जिसमें ये कमांड शामिल हैं। ठीक है, यह बहुत आसान है:

 $ ./build.sh 

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

यह काम नहीं किया! डेवलपर का समय बहुत मूल्यवान है। ठीक है, हम बिल्ड स्क्रिप्ट को संशोधित करने का प्रयास कर सकते हैं ताकि संकलन से पहले हम स्रोत और ऑब्जेक्ट फ़ाइलों के संशोधन के समय की जांच करें। और केवल उन स्रोतों को संकलित करें जिन्हें बदल दिया गया है। और सशर्त रूप से, यह कुछ इस तरह दिख सकता है:

 #!/bin/bash function modification_time { date -r "$1" '+%s' } function check_time { local name=$1 [ ! -e "$name.o" ] && return $? [ "$(modification_time "$name.c")" -gt "$(modification_time "$name.o")" ] && return $? } check_time src0 && gcc -c src0.c check_time src1 && gcc -c src1.c check_time main && gcc -c main.c gcc -o main main.o src0.o src1.o 

और अब केवल उन स्रोतों को संशोधित किया गया है जिन्हें संकलित किया जाएगा।

लेकिन क्या होता है जब परियोजना कुछ इस तरह से बदल जाती है:

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

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

• निर्भरता और लक्ष्यों के टाइमस्टैम्प का विश्लेषण
• व्युत्पन्न फ़ाइलों की प्रासंगिकता की गारंटी के लिए आवश्यक कार्य की न्यूनतम राशि
• (अच्छी तरह से, + कमांड के समानांतर निष्पादन)

makefile

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

 <  > : <  ... > <  > ... ... 

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