ฉันชอบ Makefile

 (switowski.com)
1 คะแนน โดย GN⁺ 2024-09-22 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

  • ฉันชอบ Makefile ใช้มันครั้งแรกมากว่า 10 ปีแล้ว ตอนนั้นมันก็ดูเหมือนเทคโนโลยีเก่าอยู่แล้ว เมื่อเวลาผ่านไปมี build tool ใหม่ ๆ เกิดขึ้นและหายไป แต่ Makefile ก็ยังคงถูกใช้งานอยู่ พอได้ร่วมงานในหลายโปรเจ็กต์ก็เริ่มคุ้นเคยกับมัน และเมื่อถึงจุดหนึ่งก็กลายเป็นว่าชอบมันไปแล้ว ตอนนี้มันคือเครื่องมืออัตโนมัติตัวแรกที่ฉันใช้เวลาเริ่มโปรเจ็กต์ใหม่

  • เหตุผลที่ฉันชอบ Makefile คือมันทำตามธรรมเนียมแบบไม่เป็นทางการในการกำหนดชุดคำสั่งแบบเดียวกัน เมื่อเจอโปรเจ็กต์ใหม่ ถ้ามีไฟล์ Makefile อยู่ ฉันก็จะลองรัน make หรือ make build แล้วตามด้วย make install ซึ่งจะช่วย build และตั้งค่าโปรเจ็กต์ให้เสร็จ หรืออย่างน้อยก็ทำให้รู้ว่าต้องมีขั้นตอนเพิ่มเติมอะไรบ้าง

  • ฉันพยายามใช้ธรรมเนียมเดียวกันนี้กับโปรเจ็กต์ของตัวเองด้วย ถ้าเปิดโฟลเดอร์โปรเจ็กต์เก่าแล้วรัน make dev มันจะทำทุกขั้นตอนที่จำเป็นเพื่อ build โปรเจ็กต์และรัน development server ฉันใช้เทคโนโลยีหลากหลาย แต่ละอย่างจึงมีคำสั่งต่างกันไป พอใช้ Makefile ก็ทำให้ดูแลโปรเจ็กต์ที่ไม่ได้แตะมาหลายเดือนหรือหลายปีได้ง่ายขึ้น

  • Makefile นั้นเรียบง่าย ฉันไม่ใช้เงื่อนไข, flags หรือฟีเจอร์ซับซ้อนอื่น ๆ งานส่วนใหญ่ประกอบด้วย shell command หนึ่งคำสั่งหรือมากกว่า จะเขียนเป็น bash script ที่มีฟังก์ชันเล็กน้อยก็ได้ แต่ Makefile เขียนได้ง่ายและเร็วกว่า

  • โปรเจ็กต์ส่วนตัวส่วนใหญ่มักมีงานทั่วไปประมาณนี้:

    • dev: เริ่ม development server
    • build: build โปรเจ็กต์ (ถ้าจำเป็นต้องมีขั้นตอน build)
    • deploy: deploy/เผยแพร่โปรเจ็กต์

  • บล็อกนี้มี Makefile แบบง่ายที่มี target เดียว:

    dev:  
  npm run dev

  • ในโปรเจ็กต์ที่ซับซ้อนกว่านี้ ฉันใช้ Makefile ประมาณนี้:

    # รัน development server  
dev:  
  bundle exec jekyll serve --unpublished -w --config _config.yml,_config-dev.yml --livereload  

# build assets  
build:  
  npm run gulp build  

# เฝ้าดูโฟลเดอร์ที่กำหนดและประมวลผล assets  
watch:  
  npm run gulp watch -- --wip  

# build เว็บไซต์ในเครื่อง, เข้ารหัส และ deploy ไปยังเซิร์ฟเวอร์ Netlify  
deploy:  
  JEKYLL_ENV=production bundle exec jekyll build; \  
  make encrypt; \  
  netlify deploy --prod  

# เข้ารหัสโฟลเดอร์ "_site"  
encrypt:  
  npx staticrypt _site/*.html -r -d _site

  • ในตัวอย่างข้างบนนี้กำลังละเลยเรื่องการมีอยู่ของ phony target ถ้ามีไฟล์ชื่อ dev, build, watch, deploy หรือ encrypt อยู่ Makefile อาจทำงานไม่เป็นไปตามที่คาดไว้

  • GNU Make ใช้กันอย่างแพร่หลายมาก บน Linux ก็มักจะติดตั้งมาอยู่แล้ว บน MacBook ฉันก็จำไม่ได้ว่าเคยติดตั้งมันเอง น่าจะถูกติดตั้งมาพร้อมเครื่องมืออื่น ๆ Make นั้นเรียบง่ายและมี dependency เพิ่มเติมน้อยกว่า build tool อื่น ๆ จึงมีประโยชน์ในสภาพแวดล้อมที่จำกัด มีความเป็นไปได้สูงว่าเครื่องจะมี Make อยู่แล้ว ถ้าไม่มีก็ยังสามารถรันคำสั่งใน Makefile ด้วยตัวเองผ่าน shell ได้

  • ไม่ได้หมายความว่าฉันต่อต้าน build tool อื่น ๆ เวลาเจอ build tool ใหม่ก็ยังรู้สึกน่าสนใจอยู่ แต่ฉันก็ยังใช้ Make เพื่อจัดการเครื่องมือหลากหลายแบบอยู่ดี

สรุปโดย GN⁺

  • Makefile ช่วยให้จัดการโปรเจ็กต์ได้ง่ายขึ้นด้วยการมีชุดคำสั่งที่สม่ำเสมอในหลายโปรเจ็กต์
  • ด้วยไวยากรณ์ที่เรียบง่ายและ dependency ที่น้อย จึงใช้งานได้ดีแม้ในสภาพแวดล้อมที่จำกัด
  • สามารถใช้ร่วมกับ build tool ได้หลากหลาย จึงมีความยืดหยุ่นสูง
  • เครื่องมือที่มีความสามารถคล้ายกันได้แก่ CMake, Ninja, Gradle เป็นต้น

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
kayws426 2024-09-22

หากเป็น makefile ที่ไม่ได้กำหนดการพึ่งพาไว้ การแทนที่ด้วย justfile จะให้ประสบการณ์การใช้งานที่ดีกว่า
 
GN⁺ 2024-09-22
ความคิดเห็นบน Hacker News

  • การสนับสนุนให้ใช้ Make

    • มีความเห็นว่าไม่ควรรู้สึกท้อแท้เพราะคิดว่าตัวเองใช้ Make ผิด
    • จุดเด่นของ Make คือความเรียบง่าย และสำหรับโปรเจ็กต์เล็ก ๆ ก็ไม่ได้เป็นปัญหาใหญ่
    • ในกรณีส่วนใหญ่ไม่จำเป็นต้องกังวลกับวิธีที่ถูกต้องมากนัก และจะเพิ่มความซับซ้อนเท่าที่จำเป็นเท่านั้น

  • ปัญหาของ Makefiles

    • Makefiles แย่น้อยกว่าระบบ build อื่น ๆ แต่ก็ยังมีปัญหาอยู่มาก
    • ปัญหาหลักของระบบ build:
      • พื้นฐานเกินไป: ในโปรเจ็กต์ที่ซับซ้อนจะทำให้เกิดความสับสน
      • ซับซ้อนเกินไป: ต้องใช้ความรู้ตั้งต้นและการดูแลมากเกินควร
      • ขาด standard library: ต้องนิยามทุกอย่างด้วยตัวเอง
      • จำกัดเกินไป: เมื่อความต้องการเปลี่ยนก็ต้องย้ายไปใช้ระบบอื่น
      • มีเวทมนตร์มากเกินไป: เป็นลักษณะของระบบที่ออกแบบมาไม่ดี
      • ไวยากรณ์ที่อ่านยากหรือไม่สม่ำเสมอ

  • ข้อดีของ Make

    • ความเห็นจากคนที่ชอบ Make
    • Make เป็น DSL แบบเรียบง่ายสำหรับชุดคำสั่งที่ใช้แปลงไฟล์
    • จะใช้ Bash หรือ shell อื่นก็ได้ แต่ Make ง่ายกว่า

  • การใช้ target แบบ PHONY

    • ไม่ใช้การติดตาม dependency แบบอิง mtime
    • ต้องกำหนด target ให้เป็น PHONY
    • ช่วงหลังเปลี่ยนไปใช้ just และ justfiles เพราะใช้งานได้ง่ายกว่า

  • การถกเถียงอย่างดุเดือดเกี่ยวกับ Make

    • Make จุดชนวนการถกเถียงคล้ายสงคราม vi-vs-emacs
    • การใช้ Makefile เป็นไดรเวอร์ระบบ build ระดับบนสุดถือว่าฉลาด
    • แม้จะใช้เครื่องมือ build อื่น ก็ยังทำให้เป็นมาตรฐานผ่าน Makefile ได้

  • การนำ Make ไปใช้ได้หลากหลาย

    • ใช้ Make เพื่อทำงานอัตโนมัติได้หลายแบบ
    • ใช้ Makefile สำหรับ build และ deploy เว็บไซต์ส่วนตัว
    • เรียกใช้ Make ผ่าน Git push และ Git hook
    • ใช้ Makefile สำหรับอัปโหลดและจัดการไฟล์ PDF

  • ข้อจำกัดของ Make และทางเลือกอื่น

    • Make พอใช้ได้ในฐานะตัวรันงาน แต่มีทางเลือกที่ดีกว่า
    • Make/Makefiles ไม่ได้มีมาตรฐานเดียวกัน
    • ไม่สามารถแก้ dependency ได้ จึงต้องมีสคริปต์ configure
    • ใช้ mtime เพื่อตรวจว่าอินพุตเป็นเวอร์ชันล่าสุดหรือไม่ แต่ก็อาจทำให้เกิดปัญหาได้
    • ออกแบบตามปรัชญา Unix แต่มีข้อจำกัดสำหรับระบบ build สมัยใหม่

  • การย้ายไปใช้ Justfiles

    • เปลี่ยนไปใช้ Justfiles เพื่อหลีกเลี่ยงความซับซ้อนของ Makefile

  • การใช้ Makefile แบบเรียบง่าย

    • มีความเห็นที่สนับสนุนการใช้ Makefile แบบเรียบง่าย
    • สามารถแชร์ร่วมกันได้โดยไม่ต้องเรียนรู้ทุกอย่างให้สมบูรณ์แบบ
    • มีการแชร์ประสบการณ์ที่ GitLab CI pipeline เข้ามาแทนที่ Makefile