CMake ยังไม่รู้หน้าที่ของตัวเอง
(dorinlazar.ro)CMake ยิ่งทำให้รู้สึกว่าเป็นทางออกที่แย่สำหรับ C++ มากขึ้นเรื่อย ๆ มันไม่เพียงไม่สามารถตอบโจทย์ความต้องการของนักพัฒนา C++ ได้เท่านั้น แต่ยังทำให้เรายังติดอยู่ในยุคมืดของการสร้าง makefile ด้วยภาษาที่ไม่สม่ำเสมอ คลุมเครือมาก และไร้โครงสร้าง
ปัญหา
ในโลกของการบิลด์ C++ มีปัญหาอยู่สองประเภท
- ปัญหาที่โปรเจ็กต์เดิมสร้างขึ้นเอง (หมายเหตุผู้แปล: ปัญหาในการบิลด์โปรเจ็กต์ขนาดใหญ่ที่มีอยู่แล้ว)
- ปัญหาที่เจอเมื่อเลือกเริ่มโปรเจ็กต์ใหม่ใน C++
CMake พยายามแก้ปัญหาแบบแรก และแทบไม่แก้ปัญหาแบบที่สองเลย แต่เพราะมันไม่ได้พยายามแก้ปัญหาเหล่านี้ มันจึงกลายเป็นเครื่องมือที่มีประโยชน์น้อยลง
CMake อยากเป็นตัวแปลที่แปลงคำจำกัดความของโปรเจ็กต์ให้เป็นระบบบิลด์ และมันล้มเหลวอย่างหนักในส่วนนี้ มันเป็นภาษาสำหรับกำหนดโปรเจ็กต์ที่แย่ ไม่สม่ำเสมอ และไม่เป็นธรรมชาติให้เข้าใจ
ตอนนี้คนทั้งชุมชน C++ ต่างพูดถึงเครื่องมือของ Rust เพราะ Cargo ทำสิ่งที่นักพัฒนาส่วนใหญ่คิดว่าต้องการได้จริง Cargo ดาวน์โหลด dependency จากอินเทอร์เน็ตเพื่อสร้างชุดเครื่องมือแบบแยกขาด (ซึ่งเป็นความคิดที่แย่) และให้ไลบรารีที่ลิงก์แบบสแตติกมาให้ (ซึ่งก็เป็นความคิดที่แย่เช่นกัน) ผู้คนไม่ได้ต้องการเครื่องมือที่เพิ่มช่องโหว่ด้านความปลอดภัยด้วยความเร็วมหาศาล (ผู้เขียนกำลังโต้แย้งว่าวิธีที่ Cargo ดึงโค้ดจากอินเทอร์เน็ตมาเชื่อมลิงก์โดยอัตโนมัติ อาจกลายเป็นจุดอ่อนด้านความปลอดภัย เช่น การโจมตีห่วงโซ่อุปทาน ดู I Hate Rust) แต่สิ่งที่ Cargo มอบให้จริง ๆ คือสิ่งที่จำเป็น:
- โครงสร้างโปรเจ็กต์ที่เข้มงวดมาก
- ระบบตั้งค่าที่เรียบง่ายมาก ซึ่งพึ่งพาเซิร์ฟเวอร์ภายนอกเพื่อแก้ปัญหาเรื่องไลบรารีอยู่ที่ไหน
- ชุดเครื่องมือเพียง ชุดเดียว
ผู้คนต้องการอิสระที่น้อยลงเพื่อจะได้โฟกัสกับงานจริง และไม่ได้เก่งในการเรียกใช้คอมไพเลอร์ให้สมบูรณ์แบบที่สุด
ทางออก
ตอนนี้ยังไม่มีทางออก ผมกำลังเขียน klb ในเวลาว่างอยู่ แต่ตอนนี้มันยังไม่ใช่ทางออก (ต้องใช้ทั้งเวลาและเงิน)
แต่สิ่งที่ผู้คนต้องการนั้นชัดเจน คือทางเลือกที่น้อยลง ไม่ใช่มากขึ้น การมีตัวเลือกน้อยลงหมายถึงมีวิธีทำให้การคอมไพล์โปรเจ็กต์พังได้น้อยลง
CMake ยังเป็นตัวเลือกที่ดีที่สุดในโลก C++ ตอนนี้ แต่ก็เป็นสิ่งที่เลวร้ายที่สุดที่เกิดขึ้นกับ C++ ในรอบ 20 ปีที่ผ่านมาเช่นกัน อย่างอื่นทุกอย่างกำลังดีขึ้น แต่มีแค่ระบบบิลด์ที่แย่ลงเรื่อย ๆ
10 ความคิดเห็น
ไวยากรณ์มันก็สกปรกหน่อย แต่สุดท้ายก็ไม่มีอะไรแทน CMake ได้อยู่ดี
ถ้าจะไปรันอะไรอย่าง M4 บนสภาพแวดล้อมที่ไม่ใช่ POSIX นี่ชวนปวดหัวมาก
แต่แรกก็ไม่ค่อยชอบให้สภาพแวดล้อมการบิลด์มีของพ่วงติดมาเยอะแยะอยู่แล้ว เลยไม่ค่อยอยากแตะพวก meson หรือ scone ส่วน premake ก็ดูเหมือนจะขาดอะไรไปนิด ๆ สุดท้ายก็เลยใช้ CMake แบบไม่เอาอะไรมาก กำหนดแค่โค้ดให้เรียบง่ายที่สุดแล้วใช้งานไป
ใช้ CMake มานานแบบบ่นไปด้วยตลอด แต่พอเอาเข้าจริงก็ยังไม่มีอะไรมาแทน CMake ได้อยู่ดี ส่วน bazel นี่นรกจริงๆ.. ถ้าจะเริ่มโปรเจกต์ใหม่ ก็คงลองพิจารณา meson ดูนะ
แล้ว Meson หรือ Bazel ล่ะ?
ผมเองก็ไม่ค่อยรู้เหมือนกัน เพราะไม่เคยใช้ทั้งสองอย่าง...
ส่วนตัวแล้วสำหรับโปรเจ็กต์เล็ก ๆ ผมชอบ
gprbuildเลยใช้อยู่ครับวิธีอื่นนอกจาก CMake ก็ซับซ้อนไม่ต่างกัน
อย่างน้อยก็ยังพอเป็นแบบ Cross-platform ได้.....
นั่นคงเป็นเหตุผลที่ Visual Studio ยังได้รับความนิยมอยู่ เพราะสามารถเริ่มเขียนโค้ดได้ทันที
แต่ถ้าจะเจาะรายละเอียดกันจริง ๆ เรื่องนี้ก็ถกกันได้ไม่รู้จบเหมือนกัน
แค่เห็น CMake ก็แทบจะอาเจียนแล้ว...
ผมคิดว่าควรมองว่า CMake ไม่ใช่ตัวแทนของ make แต่เป็นตัวแทนของ autotools (automake) มากกว่า
แต่ถึงอย่างนั้นก็ดูเหมือนว่ายังดีกว่า Makefile ล้วน ๆ อยู่บ้าง
เดือนที่แล้วผมมีงานต้องไปวิเคราะห์สภาพแวดล้อมการบิลด์ที่ประกอบด้วยเชลล์สคริปต์, Perl, ตัวแปรสภาพแวดล้อมของ OS และ Makefile หลายไฟล์ที่พันกันยุ่งเหยิงไปหมด บอกเลยว่าแทบจะประสาทกินครับ
ถ้าจะพยายามทำอะไรที่ละเอียดจุกจิก ก็จะหลงเข้าไปในโพรงกระต่าย...