मुझे Makefile पसंद है

• मुझे Makefile पसंद है। इसे पहली बार इस्तेमाल किए 10 साल से भी ज़्यादा हो चुके हैं। उस समय भी यह पुरानी तकनीक जैसा लगता था। समय के साथ नए build tools आए और गायब भी हो गए, लेकिन Makefile अब भी इस्तेमाल हो रहा था। अलग-अलग projects में काम करते हुए मैं इसका आदी हो गया, और किसी बिंदु पर मुझे यह सचमुच पसंद आने लगा। अब जब भी मैं कोई नया project शुरू करता हूँ, यह पहला automation tool होता है जिसका मैं इस्तेमाल करता हूँ।

• मुझे Makefile इसलिए पसंद है क्योंकि यह एक तरह की अनौपचारिक परंपरा का पालन करता है, जिसमें एक जैसे command sets लागू होते हैं। जब मैं किसी नए project में Makefile फ़ाइल देखता हूँ, तो make या make build चलाता हूँ, फिर make install चलाता हूँ, और project build होकर configure हो जाता है। या कम-से-कम मुझे आगे के अतिरिक्त steps के बारे में जानकारी मिल जाती है।

• मैं अपने projects में भी यही convention लागू करने की कोशिश करता हूँ। अगर मैं किसी पुराने project folder को खोलकर make dev चलाऊँ, तो वह project को build करने और development server चलाने के लिए ज़रूरी सारे steps पूरा कर देता है। मैंने कई तरह की technologies इस्तेमाल की हैं, और हर technology के commands अलग थे। Makefile की वजह से मैं उन projects को भी आसानी से संभाल पाता हूँ जिन्हें महीनों या सालों तक छुआ नहीं गया हो।

• Makefile सरल है। मैं conditionals, flags या दूसरी complex features का इस्तेमाल नहीं करता। ज़्यादातर काम एक या उससे ज़्यादा shell commands से बन जाते हैं। कुछ functions के साथ bash script भी लिखी जा सकती है, लेकिन Makefile लिखना ज़्यादा आसान और तेज़ है।

• मेरे ज़्यादातर personal projects में आम तौर पर ये tasks होते हैं:

  • dev: development server शुरू करना
  • build: project build करना (अगर build step की ज़रूरत हो)
  • deploy: project deploy/publish करना

• इस blog में एक बहुत ही simple Makefile है, जिसमें सिर्फ एक target है:

  dev:  
    npm run dev  
  

• ज़्यादा complex projects में मैं इस तरह का Makefile इस्तेमाल करता हूँ:

  # 개발 서버 실행  
  dev:  
    bundle exec jekyll serve --unpublished -w --config _config.yml,_config-dev.yml --livereload  
  
  # 자산 빌드  
  build:  
    npm run gulp build  
  
  # 특정 폴더 감시 및 자산 처리  
  watch:  
    npm run gulp watch -- --wip  
  
  # 로컬에서 웹사이트 빌드, 암호화 및 Netlify 서버에 배포  
  deploy:  
    JEKYLL_ENV=production bundle exec jekyll build; \  
    make encrypt; \  
    netlify deploy --prod  
  
  # "_site" 폴더 암호화  
  encrypt:  
    npx staticrypt _site/*.html -r -d _site  
  

• ऊपर के example में phony targets के होने की बात को नज़रअंदाज़ किया गया है। अगर dev, build, watch, deploy या encrypt नाम की कोई file मौजूद हो, तो Makefile उम्मीद के मुताबिक काम नहीं कर सकता।

• GNU Make बहुत व्यापक रूप से उपलब्ध है। Linux पर इसके पहले से installed होने की पूरी संभावना है। MacBook पर भी मुझे याद नहीं कि मैंने इसे अलग से install किया हो। शायद यह किसी दूसरे tool के साथ आया होगा। Make सरल है और दूसरे build tools की तुलना में इसकी अतिरिक्त dependencies कम हैं। यह सीमित environments में काम आ सकता है। बहुत संभव है कि Make पहले से मौजूद हो। और अगर न भी हो, तो Makefile के commands shell में manually चलाए जा सकते हैं।

• मैं दूसरे build tools के खिलाफ नहीं हूँ। जब भी कोई नया build tool दिखता है, मुझे दिलचस्प लगता है। लेकिन फिर भी मैं अलग-अलग tools को manage करने के लिए Make का इस्तेमाल करता हूँ।

---

GN⁺ का सार

• Makefile अलग-अलग projects में एक consistent command set देता है, जिससे management आसान हो जाती है।
• इसकी simple syntax और कम dependencies की वजह से यह सीमित environments में भी उपयोगी हो सकता है।
• इसे कई build tools के साथ इस्तेमाल किया जा सकता है, इसलिए इसकी flexibility अच्छी है।
• समान तरह के tools में CMake, Ninja, Gradle आदि शामिल हैं।

[kayws426]

यदि makefile में dependencies परिभाषित नहीं हैं, तो उसे justfile से बदलने पर बेहतर usability मिलती है.

[GN⁺]

Hacker News राय

• Make के उपयोग के लिए प्रोत्साहन

  • यह राय कि Make का गलत उपयोग करने पर निराश नहीं होना चाहिए
  • Make की ताकत उसकी सरलता है, और छोटे प्रोजेक्ट्स में यह कोई बड़ी समस्या नहीं बनती
  • ज़्यादातर मामलों में सही तरीके की चिंता करने की ज़रूरत नहीं होती, और जितनी ज़रूरत हो उतनी ही जटिलता जुड़ती है

• Makefiles की समस्याएँ

  • Makefiles दूसरे build systems की तुलना में कम बुरे हैं, लेकिन फिर भी इनमें कई समस्याएँ हैं
  • build system की मुख्य समस्याएँ:
    • बहुत बुनियादी: जटिल प्रोजेक्ट्स में भ्रम पैदा होता है
    • बहुत जटिल: शुरुआती जानकारी और maintenance की ज़रूरत जरूरत से ज़्यादा होती है
    • standard library की कमी: हर चीज़ खुद define करनी पड़ती है
    • बहुत सीमित: ज़रूरत बदलने पर किसी दूसरे system पर जाना पड़ता है
    • बहुत ज़्यादा magic: खराब डिज़ाइन किए गए systems की पहचान
    • गूढ़ या असंगत syntax

• Make के फायदे

  • Make को पसंद करने वाले व्यक्ति की राय
  • Make एक सरल DSL है, जो files को transform करने वाले commands का संग्रह है
  • Bash या किसी दूसरे shell से भी यह किया जा सकता है, लेकिन Make ज़्यादा सरल है

• PHONY target का उपयोग

  • mtime-आधारित dependency tracking का उपयोग नहीं किया जाता
  • target को PHONY के रूप में define करना चाहिए
  • हाल में just और justfiles पर स्विच किया गया है ताकि इसे और सरल तरीके से इस्तेमाल किया जा सके

• Make पर तीखी बहस

  • Make vi-vs-emacs युद्ध जैसी बहस छेड़ देता है
  • Makefile को top-level build system driver के रूप में इस्तेमाल करना समझदारी है
  • दूसरे build tools का उपयोग करने पर भी Makefile के ज़रिए standardization किया जा सकता है

• Make के विविध उपयोग

  • Make का उपयोग कई तरह के task automation के लिए किया जाता है
  • निजी वेबसाइट के build और deployment के लिए Makefile का उपयोग
  • Git push और Git hook के ज़रिए Make को कॉल करना
  • PDF files को upload और manage करने के लिए Makefile का उपयोग

• Make की सीमाएँ और विकल्प

  • Make task runner के रूप में ठीक है, लेकिन इससे बेहतर विकल्प मौजूद हैं
  • Make/Makefiles standardized नहीं हैं
  • dependency resolution संभव नहीं, configure script की ज़रूरत होती है
  • input नया है या नहीं, यह जाँचने के लिए mtime का उपयोग होता है, लेकिन इससे समस्याएँ हो सकती हैं
  • Unix दर्शन के अनुसार डिज़ाइन किया गया है, लेकिन modern build systems के लिए इसकी सीमाएँ हैं

• Justfiles पर स्विच

  • Makefile की जटिलता से बचने के लिए Justfiles पर स्विच किया गया

• Makefile का सरल उपयोग

  • Makefile के सरल उपयोग का समर्थन करने वाली राय
  • सब कुछ पूरी तरह सीखे बिना भी इसे साझा किया जा सकता है
  • GitLab CI pipeline ने Makefile की जगह ले ली, ऐसा अनुभव साझा किया गया