การใช้ Make ถือว่าล้าสมัยหรือไม่ [ปิด]

31

ดังนั้นฉันจึงเจอหลายความคิดเห็น / โพสต์ / อื่น ๆ เกี่ยวกับการสร้าง makefiles โดยตรงและมันเป็นเรื่องโง่ที่ต้องทำในปี 2015 ฉันรู้เครื่องมือต่าง ๆ เช่น CMake และฉันใช้ CMake บ่อยครั้งมาก CMake กำลังสร้าง Makefile ให้คุณและช่วยในการลบความน่าเบื่อของการทำมันด้วยตัวคุณเอง แน่นอนว่ามันเพิ่มคุณสมบัติที่ยอดเยี่ยมอื่น ๆ อีกมากมาย ... แต่มันก็ยังเป็น Makefile ในที่สุด

ดังนั้นคำถามของฉันคือการพูดคุย 'ล้าสมัย' เกี่ยวกับการอ้างอิงถึงยูทิลิตี้ Make ทั้งหมดหรือเพียงแค่ความคิดในการเขียน Makefiles ของคุณเองหรือไม่ ฉันไม่ได้ใช้ IDE สำหรับการพัฒนา C / C ++ เลย (แค่ emacs) ดังนั้นฉันจึงเขียน Makefiles เสมอ

ถ้า Make ถือว่าล้าสมัยแล้ว C / C ++ dev ควรใช้อะไรในการสร้างโครงการส่วนบุคคลขนาดเล็ก

— JParrilla
แหล่งที่มา

8

สำหรับโครงการขนาดเล็กส่วนบุคคลที่makeไม่มี Makefile ก็เพียงพอแล้ว สิ่งที่ยุ่งยาก?

— ott--

8

ซอฟต์แวร์ที่มีอยู่ทุกชิ้นในระบบ FreeBSD ของฉันทั้งเดสก์ท็อปและเซิร์ฟเวอร์มี Makefile ที่เริ่มต้นด้วย 'สร้าง' เลขที่ 'ทำ' ไม่ล้าสมัย

— Rob

3

ผู้คนมีอิสระในการใช้ IDEs แต่ถ้า IDE ของพวกเขาไม่สามารถสนับสนุนโครงการที่ใช้ Makefiles ได้เกือบ 40 ปีหลังจากmakeเขียนครั้งแรกพวกเขาก็ไม่ควรคาดหวังให้คนอื่นทำงานด้วย

— Miles Rout

1

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

— rwong

1

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

— shuva

30

ความแตกต่างที่สำคัญคือ CMake เป็นระบบเมตาบิลด์ข้ามแพลตฟอร์ม โปรเจ็กต์ CMake เดียวสามารถสร้างไฟล์ Unix / Linux ปกติ, โครงการ Visual Studio สำหรับ Windows, โครงการ XCode สำหรับ Mac และระบบอื่น ๆ ที่ไม่ใช่เมตาบิลด์ที่คุณอาจต้องการใช้หรือสนับสนุน

ฉันจะไม่บอกว่าการใช้ make โดยตรงหรือแม้กระทั่งการแก้ไข makefiles ด้วยตนเองคือ "ล้าสมัย" แต่สิ่งเหล่านั้นเป็นสิ่งที่คุณไม่ควรทำถ้าคุณกำลังทำงานกับ Unix / Linux สิ่งที่ไม่ต้องใช้พอร์ตกับ Windows เหมือนกับที่คุณทำ ไม่ควรแก้ไขไฟล์โครงการ Visual Studio โดยตรงหากคุณต้องการพอร์ตไฟล์เหล่านั้นไม่ใช่ Windows หากคุณมีความสนใจในการพกพามันคุ้มค่าที่จะเรียนรู้ระบบ meta-build เช่น Scons หรือ CMake

— Ixrec
แหล่งที่มา

9

POSIX makeเป็นข้ามแพลตฟอร์ม

— Blrfl

6

@Blrfl อาจเป็นจริง แต่โดยทั่วไปคุณจะพบบรรทัดคำสั่งที่คุณต้องใช้ในการรวบรวมและ / หรือเชื่อมโยงโครงการของคุณเป็นแพลตฟอร์มเฉพาะแม้ว่าแพลตฟอร์มทั้งหมดที่คุณกำหนดเป้าหมายนั้นเป็นไปตาม POSIX และแม้ว่าคุณจะ 'อีกครั้งโดยใช้คอมไพเลอร์เหมือนกันในทุก (มีจะยังคงมีปัญหาที่น่ารำคาญกับสถานที่ของการรวมไฟล์ไม่ว่าคุณต้องการ-lm, -lnslและอื่น ๆ หรือไม่ว่าสิ่งอำนวยความสะดวกเหล่านี้จะรวมอยู่ในห้องสมุด C ฯลฯ )

— จูลส์

5

@Jules มีมากขึ้น (หรือน้อยกว่า) CMakeมันถูกปรับแต่งโดยทั่วไปเพื่อการสร้างแอพพลิเคชั่นแบบโมดูลาร์ของคุณสำหรับระบบที่มีตัวตัก ELF และให้ข้อมูลสรุปเกี่ยวกับเครื่องมือทั้งหมดที่จำเป็นสำหรับห่วงโซ่เครื่องมือเฉพาะนั้น หากคุณออกจาก toolchain นั้น (เช่น linker script ที่กำหนดเองสำหรับโลหะเปลือย) CMakeทันใดนั้นก็ไม่ได้ให้การสนับสนุนหรือความสะดวกในการพกพาเลยคุณก็แฮ็คมันได้เช่นเดียวกับที่คุณเคยแฮ็คสคริปต์สร้างแบบกำหนดเองทั้งหมด

— Ext3h

ไปเหมือนกันสำหรับการทำQ (แม้จะไม่ใช่การทำเอกสารที่ไม่สอดคล้องกันอย่างไม่สอดคล้องกัน ** ap CMake คือ), btw;)

— mlvljr

11

เป็นmakeล้าสมัยจริงๆ?

ฉันไม่คิดอย่างนั้น ในท้ายที่สุด make ยังคงมีประสิทธิภาพเพียงพอที่จะให้การทำงานทั้งหมดที่ต้องการเช่นการรวบรวมเงื่อนไขของแหล่งที่เปลี่ยนแปลงและเหมือนกัน การบอกว่าmakeล้าสมัยจะเหมือนกับว่าการเขียนสคริปต์ตัวเชื่อมโยงที่กำหนดเองนั้นล้าสมัยแล้ว

แต่สิ่งที่makeไม่ได้จัดเตรียมไว้คือฟังก์ชั่นเพิ่มเติมและคลังเก็บสต็อคเพื่อความสะดวกสบายเช่นการสร้างส่วนหัวแบบ Parametric เฟรมเวิร์กการทดสอบแบบรวมหรือแม้แต่ไลบรารีแบบมีเงื่อนไขโดยทั่วไป

ในทางCMakeตรงข้ามได้รับการปรับแต่งโดยตรงไปสู่การสร้างไลบรารี่และเอ็กซีคิวต์ทั่วไปของเอลฟ์ เมื่อใดก็ตามที่คุณออกจากกระบวนการที่กำหนดไว้ล่วงหน้าคุณจะต้องเริ่มแฮ็คCMakeเช่นเดียวกับที่คุณเคยแฮ็ก Makefiles ของคุณเอง

เมื่อพิจารณาว่าคุณสามารถสร้าง C ++ ได้มากกว่าแอปพลิเคชันเฉลี่ยของคุณสำหรับระบบที่รู้จักกับตัวโหลดเอลฟ์CMakeแน่นอนว่าไม่เหมาะสำหรับทุกสถานการณ์ อย่างไรก็ตามหากคุณกำลังทำงานในสภาพแวดล้อมที่ได้มาตรฐานCMakeหรือกรอบงานตัวสร้างสคริปต์ที่ทันสมัยเหล่านี้เป็นเพื่อนที่ดีที่สุดของคุณอย่างแน่นอน

ขึ้นอยู่กับความเชี่ยวชาญของแอปพลิเคชันของคุณและโครงสร้างของCMakeเฟรมเวิร์กนั้นเหมาะกับการทำงานของคุณมากเพียงใด

— Ext3h
แหล่งที่มา

ในขณะที่มีประโยชน์ make เป็นระบบที่น่ากลัวด้วยการสร้าง braindead, arcane syntax และข้อ จำกัด ที่ไม่จำเป็นจำนวนมาก

— antred

7

กาลครั้งหนึ่งนานมาแล้วภาษาระดับสูงเป็นเพียงความคิด ผู้คนพยายามใช้คอมไพเลอร์ เมื่อก่อนมีข้อ จำกัด ด้านฮาร์ดแวร์ที่รุนแรง - ไม่มีเครื่องมือกราฟิกดังนั้น "ข้อความธรรมดา" จึงถูกนำมาใช้สำหรับรูปแบบไฟล์อินพุต คอมพิวเตอร์มักจะมี RAM น้อยมากดังนั้นซอร์สโค้ดจะต้องถูกแยกเป็นชิ้น ๆ และคอมไพเลอร์ก็แบ่งออกเป็นยูทิลิตี้แยกต่างหาก (ตัวประมวลผลล่วงหน้าคอมไพเลอร์แอสเซมเบลอร์ linker) ซีพียูทำงานช้าและมีราคาแพงดังนั้นคุณจะไม่สามารถปรับแต่งให้เหมาะสมได้

แน่นอนว่ามีซอร์สไฟล์จำนวนมากและยูทิลิตี้มากมายที่ใช้สร้างไฟล์ออบเจ็กต์จำนวนมากมันเป็นระเบียบในการสร้างทุกอย่างด้วยตนเอง ในฐานะที่เป็นข้อบกพร่องสำหรับการออกแบบในเครื่องมือ (เกิดจากฮาร์ดแวร์ที่ จำกัด อย่างรุนแรง) ผู้คนเริ่มเขียนสคริปต์เพื่อกำจัดความยุ่งยากบางอย่าง

น่าเศร้าที่สคริปต์มีความอึดอัดและยุ่งเหยิง เพื่อหลีกเลี่ยงปัญหาที่เกิดขึ้นกับสคริปต์ (ซึ่งการทำงานรอบสำหรับข้อบกพร่องในการออกแบบเครื่องมือที่เกิดจากฮาร์ดแวร์ จำกัด ) makeในที่สุดคนคิดค้นระบบสาธารณูปโภคที่จะทำให้สิ่งที่ง่ายเช่น

อย่างไรก็ตาม; makefiles อึดอัดและยุ่งเหยิง เพื่อแก้ไขปัญหาเกี่ยวกับ makefiles (ซึ่งเป็นการแก้ไขปัญหาสำหรับข้อบกพร่องในการออกแบบในเครื่องมือที่เกิดจากฮาร์ดแวร์ที่ จำกัด ) ผู้คนเริ่มทำการทดลองกับ makefiles ที่สร้างขึ้นโดยอัตโนมัติ เริ่มต้นด้วยสิ่งต่าง ๆ เช่นการรวบรวมคอมไพเลอร์เพื่อสร้างการพึ่งพา และนำไปสู่เครื่องมือต่างๆเช่น auto-conf และ cmake

นี่คือที่เราอยู่ตอนนี้: การทำงานรอบ ๆ เพื่อหางานสำหรับข้อบกพร่องในการออกแบบในเครื่องมือที่เกิดจากฮาร์ดแวร์ที่ จำกัด

มันเป็นความคาดหวังของฉันว่าภายในสิ้นศตวรรษนี้จะมีอีกสองสามเลเยอร์ของ "การทำงานเพื่อการทำงาน" บนกองที่มีอยู่ ข้อ จำกัด ด้านฮาร์ดแวร์ที่รุนแรงซึ่งทำให้สิ่งเหล่านี้หายไปเมื่อหลายสิบปีก่อนและเหตุผลเดียวที่เรายังคงใช้ระเบียบแบบโบราณในตอนนี้ก็คือ " นี่คือสิ่งที่ทำกันมาตลอด "

— เบรนแดน
แหล่งที่มา

1

ดังนั้นทางเลือกคืออะไร? ทางเลือกเปลี่ยนแนวคิดการสร้างโดยสิ้นเชิงหรือไม่?

— JParrilla

1

@ Darkslash: เมื่อคุณเริ่มพิจารณาทางเลือก (สมมุติ) มันเหมือนกับการเปิดประตูระบายน้ำ - คุณจบลงด้วยการตั้งคำถามทุกอย่าง (และจบลงด้วยความคิดเช่นการแยกความหมายและไวยากรณ์และการออกแบบ IDEs และเครื่องมือและการส่งมอบเป็นชุด ปริศนาขนาดใหญ่) ในทางปฏิบัติมากขึ้นคือการตระหนักว่าเครื่องมือเช่นcmakeรักษาอาการเท่านั้นและไม่สามารถรักษาสาเหตุ / s; ซึ่งทำให้ง่ายต่อการยอมรับความจริงที่ว่าคุณไม่มีทางเลือกอื่นนอกจากใช้เครื่องมือที่อาจไม่ใกล้เคียงกับ "อุดมคติ"

— เบรนแดน

5

Makefiles ไม่ได้ 'งุ่มง่ามและยุ่งเหยิง' แต่อย่างใด พวกมันสวยงามอย่างไม่น่าเชื่อ: makeเป็นหัวใจสำคัญของเครื่องยนต์ในการสำรวจกราฟการพึ่งพาแบบวนรอบ ไม่มีอะไรเกี่ยวกับ 'สคริปต์' หรือบรรทัดคำสั่งคือ 'archaic'

— Miles Rout

1

@MilesRout: ส่วนที่น่าอึดอัดใจและยุ่งคือการสร้างกราฟ การสำรวจเส้นทางมีความสง่างามพอสมควร แต่เพียงนำตัวอย่างที่พบบ่อยที่สุดของไฟล์ส่วนหัวที่ยุ่งเหยิง: C แต่ละอัน#includeมีขอบ แต่makeไม่สามารถแยกไฟล์ C ได้ ยังไม่เป็นปัญหาเพราะmakeสามารถจัดเก็บขอบเหล่านี้ด้วยโหนดถัดไป (ไฟล์ * .o) แต่ก็ไม่ได้ทำเช่นนั้น

— MSalters

3

ฉันไม่เห็นด้วยว่าการออกแบบที่ดีกว่านั้นเป็นไปได้ makeไม่ใช่แค่การรวบรวม C! คุณต้องการโปรแกรมที่ใช้.cและ.hไฟล์และช่วยให้Makefiles แต่นั่นไม่ใช่makeและนั่นไม่ใช่สิ่งที่makeควรทำ อีกครั้งmakeไม่ใช่ทั้งหมดที่เกี่ยวกับ C และโซลูชันเฉพาะสำหรับ C makeเป็นแนวคิดที่ไม่ดี (และบังเอิญละเมิดปรัชญา UNIX)

— เส้นทาง Miles Rout

5

make (เครื่องมือหรือการใช้งานโดยตรงผ่าน Makefile) ไม่ล้าสมัยโดยเฉพาะอย่างยิ่งสำหรับ "โครงการขนาดเล็กส่วนบุคคล" ตามที่คุณใช้

แน่นอนคุณสามารถใช้สำหรับโครงการขนาดใหญ่รวมถึงโครงการที่กำหนดเป้าหมายสำหรับหลายแพลตฟอร์ม ด้วยตัวแปรเฉพาะเป้าหมายคุณสามารถปรับแต่งวิธีการสร้างแพลตฟอร์มที่แตกต่างกันได้อย่างง่ายดาย ทุกวันนี้ลีนุกซ์ลีนุกซ์มาพร้อมกับ cross-compiling toolchains (เช่นmingw-w64 ) เพื่อให้คุณสามารถสร้างชุดซอฟต์แวร์ Windows ที่สมบูรณ์ (พร้อมตัวติดตั้งหากคุณต้องการ) จาก Linux ทั้งหมดขับเคลื่อนจาก Makefile ของคุณ

เครื่องมืออย่างcmakeและqmakeอาจมีประโยชน์ แต่ไม่มีปัญหา พวกเขามักจะดีสำหรับการสร้างแอปพลิเคชันตัวเองพร้อมกับห้องสมุดใด ๆ (แม้ว่าฉันมักจะมีปัญหากับ qmake ทำการตรวจสอบการพึ่งพาที่เหมาะสมระหว่างห้องสมุดและโปรแกรมที่ใช้พวกเขา) แต่ฉันมักจะต่อสู้กับข้อ จำกัด ของเครื่องมือเหล่านั้น งาน (การสร้างโปรแกรมติดตั้งการสร้าง / ติดตั้งเอกสารหรือไฟล์แปลทำสิ่งผิดปกติเช่นเปลี่ยนการเก็บถาวรเป็นห้องสมุดสาธารณะ ฯลฯ ) ทั้งหมดนี้สามารถทำได้makeแม้ว่าสิ่งต่าง ๆ เช่นการติดตามการพึ่งพาอาจต้องใช้ความพยายามเล็กน้อย

IDEs เช่น Qt Creator และ Eclipse ยังสามารถนำเข้าโครงการที่ใช้ Makefile ดังนั้นคุณสามารถแบ่งปันกับนักพัฒนาที่ใช้ IDE ได้ ฉันคิดว่า Qt Creator IDE เป็นเลิศในฐานะ C ++ IDE แต่หลังจากใช้เวลาสักพักเพื่อให้มีประสิทธิภาพมากขึ้นกับ Emacs และเนื่องจากฉันทำการพัฒนา Ada มากขึ้นฉันจึงพบว่าตัวเองชอบ Emacs มากขึ้นสำหรับทุกสิ่ง ในการเชื่อมโยงกลับไปที่คำถามเกี่ยวกับmakeในขั้นตอนหลังการเชื่อมโยงใน Makefile ของฉันฉันจะอัปเดตไฟล์ TAGS ของฉัน (สำหรับการนำทางสัญลักษณ์ใน Emacs) ซึ่งเต็มไปด้วยM-x visit-tags-table:

find $(SRC_DIR) $(TEST_DIR) -regex ".*\.[ch]\(pp\)?" -print | etags -

หรือสำหรับการพัฒนา Ada:

find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -

— แพทริค
แหล่งที่มา

2

คำตอบนี้เติมเต็ม @lxrec คำตอบ

Makefiles สามารถใช้ได้หลายอย่างไม่เพียง แต่สร้างโปรแกรม / ไลบรารีจากซอร์สโค้ด ระบบ Build เช่น CMake หรือ autotools ได้รับการออกแบบให้ใช้รหัสและสร้างในลักษณะที่เหมาะสมกับแพลตฟอร์มของผู้ใช้ (เช่นค้นหาไลบรารีหรือระบุตัวเลือกการคอมไพล์ที่ถูกต้อง) ตัวอย่างเช่นคุณสามารถมี makefile ซึ่งจะช่วยให้งานรีลีสบางอย่างโดยอัตโนมัติเช่น: สร้างไฟล์ zip ที่มีรหัสด้วยเวอร์ชันที่ได้มาจาก git; ทำการทดสอบกับรหัสของคุณ อัพโหลดกล่าวว่าไฟล์ zip ไปยังบริการโฮสติ้ง ระบบการสร้างบางระบบ (เช่น automake) อาจจัดเตรียมวิธีที่ง่ายในการทำสิ่งนี้ระบบอื่นอาจไม่

ไม่ได้หมายความว่าคุณต้องใช้ makefiles สำหรับสิ่งนี้คุณสามารถใช้ภาษาสคริปต์ (shell, python และอื่น ๆ ) สำหรับงานดังกล่าว

— James Tocknell
แหล่งที่มา

1

ฉันไม่คิดว่ามนุษย์เขียนMakefile-s ล้าสมัยโดยเฉพาะเมื่อ:

ใช้ POSIX make ซึ่งช่วยให้คุณพกพาได้ Makefile
หรือการใช้ GNU make 4 ซึ่งให้คุณสมบัติที่น่าสนใจมากมายโดยเฉพาะอย่างยิ่งความสามารถในการเขียนสคริปต์ของ GUILE ซึ่งช่วยให้สามารถเขียนโค้ดคุณสมบัติแฟนซีที่Makefileกำเนิดโดยผู้สร้างได้อย่างมีประสิทธิภาพ(ผมเชื่อว่าคุณลักษณะของ autotools หรือ Cmake สามารถเขียนได้ง่าย ) แน่นอนว่าราคาที่ต้องจ่ายคือต้องใช้ GNU ทำ 4 (ไม่ใช่เรื่องใหญ่ IMHO)

— Basile Starynkevitch
แหล่งที่มา

0

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

ในทำนองเดียวกันถ้าสิ่งที่คุณต้องการคือวิธีหลีกเลี่ยงการเขียนออกมาg++ -g src/*.c -o blah -W -Wall -Werror && ./blahตลอดเวลา Makefile ที่เขียนด้วยมือนั้นสมบูรณ์แบบ!

หากคุณต้องการสร้างสิ่งที่พกพาได้สูงโดยที่คุณไม่ต้องจัดการกับการพกพานั้นเองคุณอาจต้องการ Autotools เพื่อสร้าง Makefile ที่เหมาะสมสำหรับคุณ Autotools จะตรวจจับคุณสมบัติที่รองรับโดยแพลตฟอร์มต่าง ๆ โปรแกรมที่เขียนในมาตรฐาน C89 ที่สร้างขึ้นด้วย Autotools จะรวบรวมได้ทุกที่

— เส้นทางไมล์
แหล่งที่มา

"จะรวบรวมแทบทุกที่" -> "จะรวบรวมในระบบที่คล้าย Unix ล่าสุด" ฉันไม่คิดว่าautotoolsจะทำงานได้ในระดับใดก็ตามที่เกี่ยวข้องในระบบ Windows เช่น (ลดราคา Cygwin / MingW ซึ่งเป็นระบบที่เหมือน Unix ที่อยู่ด้านบนของ Windows)

— sleske

มันไม่เกี่ยวอะไรกับการเป็นคนล่าสุด ข้อดีของ autotools คือมันทำงานได้กับทุกระบบเหมือน POSIX จากระยะไกล Windows ค่อนข้างเข้ากันได้กับ POSIX

— Miles Rout

ใช่ฉันยืนแก้ไขแล้ว ที่จริงแล้วฉันจำได้ว่าการวิพากษ์วิจารณ์ Autotools หนึ่งครั้งนั้นแม่นยำว่ามีรหัสแม้ในระบบที่เก่ามาก ฉันยังคงอยู่ข้างๆส่วน Windows แม้ว่า

— sleske

และความผิดสำหรับที่อยู่ทั้งหมดกับ Microsoft หากพวกเขาสนใจเกี่ยวกับการผลิตผลิตภัณฑ์ที่มีคุณภาพ Windows จะได้รับการสนับสนุนที่เหมาะสมสำหรับมาตรฐานระบบปฏิบัติการระหว่างประเทศ (เช่น POSIX) POSIX ไม่ได้เป็นเพียงสิ่ง "ยูนิกซ์" ก็มาตรฐานระบบปฏิบัติการแบบพกพาสำหรับระบบปฏิบัติการทั้งหมด Windows เป็นเพียงกองขยะที่ไม่สามารถทำตามได้

— Miles Rout

@MilesRout ยังคงเป็นบรรทัดล่างคือว่า "แทบทุกที่" ไม่รวม90% คอมพิวเตอร์เดสก์ทอป

— el.pescado

-2

หากโครงการของคุณง่ายและมีไฟล์น้อยมากดังนั้นไม่จำเป็นต้องสร้างไฟล์

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

หากคุณต้องการลบไฟล์เก่า / คอมไพล์ / ลิงค์ / ติดตั้งด้วยจำนวนขั้นต่ำของความยุ่งยากและโอกาสที่จะเกิดข้อผิดพลาดในการกดคีย์ makefile นั้นเป็นประโยชน์อย่างแท้จริง

เมื่อคุณเข้าสู่โครงการ 'โลกแห่งความจริง' แทบจะไม่เคยมีเพียง 1 หรือ 2 ไฟล์ แต่เป็นไฟล์นับร้อย makefile จะทำการกระทำที่ถูกต้องเสมอและไม่มีการกระทำที่ไม่จำเป็น (หลังจาก debugged) ดังนั้นคุณจะพิมพ์คำสั่งง่ายๆเดียวเท่านั้นและ makefile จะทำงานทั้งหมด

— user3629249
แหล่งที่มา

1

นั่นไม่ได้ตอบว่าทำไมถึงชอบmakeมากกว่าcmakeหรือกลับกัน

— Ext3h

การใช้ makefiles จะไม่สร้างไฟล์ทั้งหมดใหม่ทุกครั้ง (อย่างอื่น CMake หรือเครื่องมืออัตโนมัติไม่สามารถใช้งานได้)

— ideasman42