อะไรคือความแตกต่างระหว่าง Autotools, Cmake และ Scons?

259

หัวข้อนี้มีการกล่าวถึงในScons wikiแล้ว ฉันขอแนะนำให้คุณเยี่ยมชมลิงค์ต่อไปนี้: 1. scons.org/wiki/SconsVsOtherBuildToolsคุณเคยไปที่หัวข้อสนทนาที่คล้ายกันมากในUbuntu Forumหรือไม่?

— bhadra

คุณสามารถตรวจสอบ pdf นี้ได้ที่www-alt.gsi.de/documents/DOC-2007-Sep-17-1.pdf ; มันมีข้อดีข้อเสียและรายละเอียดบางอย่างเกี่ยวกับแต่ละเครื่องมือ

— อดัม

190

ในความเป็นจริง Autotools 'เพียง' ประหยัด 'ที่แท้จริงเท่านั้นก็คือมันเป็นสิ่งที่โครงการ GNU ทั้งหมดใช้เป็นส่วนใหญ่

ปัญหาเกี่ยวกับ Autotools:

ไวยากรณ์ของแมโคร ARCANE m4 แท้จริงรวมกับ verbose, การเขียนสคริปต์เชลล์แบบบิดเบี้ยวสำหรับการทดสอบสำหรับ "ความเข้ากันได้" เป็นต้น
หากคุณไม่ได้สนใจคุณจะสับสนกับความสามารถในการรวบรวมข้าม (ควรสังเกตอย่างชัดเจนว่า Nokia มาพร้อมกับ Scratchbox / Scratchbox2 ไปที่Autotools ที่สร้างขึ้นอย่างมากสำหรับ Maemo / Meego) เหตุผลมีเส้นทางคงที่ในการทดสอบของคุณคุณจะหยุดการสนับสนุนข้ามคอมไพล์เพราะมันจะไม่เป็นไปตามข้อกำหนดของ sysroot และมันจะดึงสิ่งต่าง ๆ ออกจากระบบโฮสต์ของคุณ หากคุณหยุดการสนับสนุนข้ามคอมไพล์มันจะทำให้โค้ดของคุณใช้งานไม่ได้สำหรับสิ่งต่างๆเช่น OpenEmbedded และทำให้ "สนุก" สำหรับการแจกแจงที่พยายามสร้างการเผยแพร่ใน cross-compiler แทนเป้าหมาย
มีการทดสอบจำนวนมากสำหรับปัญหาเกี่ยวกับคอมไพเลอร์เก่าที่ใช้งานไม่ได้ซึ่งปัจจุบันไม่มีใครใช้กับการผลิตอะไรในวันนี้และอายุมาก เว้นแต่ว่าคุณกำลังสร้างอะไรบางอย่างเช่น glibc, libstdc ++ หรือ GCC ในSolaris, AIX หรือรุ่นที่เก่าแก่อย่างแท้จริงการทดสอบนี้เป็นการเสียเวลาและเป็นแหล่งที่มาของสิ่งต่างๆ
มันเป็นประสบการณ์ที่เจ็บปวดมากที่ได้รับการตั้งค่า Autotools เพื่อสร้างรหัสที่ใช้งานได้สำหรับระบบ Windows (ในขณะที่ฉันใช้ Windows เพียงเล็กน้อย แต่เป็นเรื่องที่น่ากังวลอย่างมากหากคุณกำลังพัฒนาโค้ดข้ามแพลตฟอร์มโดยเจตนา)
เมื่อมันพังคุณจะต้องใช้เวลาหลายชั่วโมงไล่ล่าหางของคุณเพื่อพยายามแยกแยะสิ่งที่ใครก็ตามที่เขียนสคริปต์ผิดเพื่อแยกแยะงานสร้างของคุณ (อันที่จริงนี่คือสิ่งที่ฉันพยายามจะทำ (หรือมากกว่านั้น) ตัดออก Autotools อย่างสมบูรณ์ - ฉันสงสัยว่ามีเวลามากพอในช่วงที่เหลือของเดือนนี้เพื่อแยกความยุ่งเหยิงออก ... ) สำหรับการทำงานในขณะนี้ขณะที่ฉันพิมพ์สิ่งนี้ Apache Thrift มีหนึ่งในระบบสร้างBROKENที่จะไม่ข้าม -รวบรวม.)
จริง ๆ แล้วผู้ใช้ "ปกติ" ไม่เพียงแค่ทำ "./configure; make" - สำหรับหลาย ๆ สิ่งพวกเขากำลังจะดึงแพ็คเกจที่จัดทำโดยใครบางคนเช่น PPA หรือผู้จัดจำหน่ายของพวกเขา ผู้ใช้ "ปกติ" ไม่ใช่ devs และไม่คว้า tarballs ในหลายกรณี นั่นคือหัวสูงในส่วนของทุกคนสำหรับการสันนิษฐานว่าจะเป็นกรณีที่มี ผู้ใช้ทั่วไปสำหรับ tarballs กำลังทำสิ่งต่าง ๆ อยู่ดังนั้นพวกเขาจะถูกกระแทกอย่างรุนแรงหากมี

มันใช้งานได้ ... ส่วนใหญ่แล้ว ... คือทั้งหมดที่คุณสามารถพูดเกี่ยวกับ Autotools มันเป็นระบบที่แก้ปัญหาต่าง ๆ ที่เกี่ยวข้องกับโครงการ GNU จริง ๆ เท่านั้น ... สำหรับรหัสหลัก toolchain หลักของพวกเขา (แก้ไข (05/24/2014): ควรสังเกตว่าข้อกังวลประเภทนี้เป็นสิ่งที่ไม่ดีที่อาจเป็นกังวลเกี่ยวกับ - Heartbleed บางส่วนเกิดจากความคิดนี้และด้วยระบบที่ถูกต้องและทันสมัยคุณจริงๆไม่มีธุรกิจใดเกี่ยวข้องกับ Autotools ที่แก้ไขให้ถูกต้อง GNU อาจจำเป็นต้องทำการลบ cruft ของ codebase เนื่องจากสิ่งที่เกิดขึ้นกับ Heartbleed) คุณสามารถใช้มันเพื่อทำโครงการของคุณและมันอาจทำงานได้ดีสำหรับโครงการขนาดเล็กที่คุณไม่คาดหวังว่าจะทำงานได้ทุกที่ยกเว้น Linux หรือที่ไหน toolchain ของ GNU ทำงานอย่างถูกต้องอย่างชัดเจน คำสั่งว่า "บูรณาการอย่างกับลินุกซ์" เป็นค่อนข้างงบหนาและค่อนข้างไม่ถูกต้อง มันทำงานร่วมกับเครื่องมือของ GNU ได้ดีพอสมควรและแก้ปัญหาที่ไอทีมีกับเป้าหมาย

นี่ไม่ใช่การบอกว่าไม่มีปัญหากับตัวเลือกอื่น ๆ ที่กล่าวถึงในเธรดที่นี่

SCons เป็นสิ่งทดแทนสำหรับ Make / GMake / etc และดูดีสวยทุกสิ่งถือว่าเป็นอย่างไร ...

มันยังคงเป็นเพียงเครื่องมือ POSIX เท่านั้น คุณอาจได้รับ MinGW เพื่อสร้างสิ่ง Windows ได้ง่ายกว่าด้วย Autotools แต่มันก็ยังเหมาะที่จะทำ POSIX และคุณต้องติดตั้ง Python และ SCons เพื่อใช้งาน
มันมีปัญหาในการทำการรวบรวมข้ามเว้นเสียแต่ว่าคุณกำลังใช้งานอย่าง Scratchbox2
ช้ากว่าและมีเสถียรภาพน้อยกว่า CMake เป็นที่ยอมรับจากการเปรียบเทียบของพวกเขาเอง พวกเขาคิดครึ่งใจ (ด้าน POSIX ต้องการสร้าง / gmake เพื่อสร้าง ... ) เชิงลบสำหรับ CMake เทียบกับ SCons (นอกจากนี้หากคุณต้องการความช่วยเหลือที่มากเกินกว่าโซลูชันอื่น ๆ คุณควรถามตัวเองว่าโครงการของคุณซับซ้อนเกินไป ... )

ตัวอย่างที่ให้สำหรับ CMake ในเธรดนี้เป็นบิตปลอม

อย่างไรก็ตาม ...

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

ในความจริงแล้วเป้าหมายของคุณควรกำหนดสิ่งที่คุณเลือกที่นี่

คุณจำเป็นต้องจัดการกับtoolchains ที่หักจำนวนมากเพื่อสร้างไบนารี่ที่ใช้งานได้หรือไม่? ถ้าใช่คุณอาจต้องการพิจารณา Autotools โดยตระหนักถึงข้อเสียที่ฉันได้กล่าวไว้ข้างต้น CMake สามารถรับมือกับสิ่งเหล่านี้ได้มากมาย แต่ก็กังวลน้อยลงกว่าที่ Autotools ทำ SCons สามารถขยายออกไปได้เพื่อให้เกิดความกังวล แต่ก็ไม่ใช่คำตอบที่ไม่เหมาะสม
คุณมีความจำเป็นต้องกังวลเกี่ยวกับเป้าหมายของ Windows หรือไม่? ถ้าเป็นเช่นนั้น Autotools ควรจะทำงานไม่ได้ ถ้าเป็นเช่นนั้น SCons อาจ / อาจไม่ใช่ทางเลือกที่ดี ถ้าเป็นเช่นนั้น CMake เป็นตัวเลือกที่ดี
คุณมีความต้องการที่จะกังวลเกี่ยวกับการรวบรวมข้าม (แอพสากล / ห้องสมุด, สิ่งต่างๆเช่น Google Protobufs, Apache Thrift, และอื่น ๆควรสนใจเรื่องนี้หรือไม่?) ถ้าเป็นเช่นนั้น Autotools อาจทำงานให้คุณตราบใดที่คุณไม่ต้องกังวลกับ Windows แต่คุณจะต้องใช้เวลามากมายในการบำรุงรักษาระบบกำหนดค่าของคุณเมื่อสิ่งต่างๆเปลี่ยนแปลงไป SCons แทบจะไม่ต้องลงมือเลยในตอนนี้เว้นแต่ว่าคุณจะใช้ Scratchbox2 - จริงๆมันไม่มีที่จับบนการคอมไพล์ข้ามและคุณจะต้องใช้ความสามารถนั้นและรักษามันในลักษณะเดียวกัน คุณจะใช้ Automake ถ้าเป็นเช่นนั้นคุณอาจต้องการที่จะต้องพิจารณา CMake เพราะมันสนับสนุนข้ามรวบรวมโดยไม่ต้องเป็นจำนวนมากของความกังวลเกี่ยวกับการรั่วไหลออกจาก sandbox และจะทำงานร่วมกับ / ไม่มีอะไรเช่น Scratchbox2 และรวมไว้เป็นอย่างดีกับสิ่งที่ต้องการ OpenEmbedded

มีเหตุผลหลายโครงการหลายโครงการกำลังทำ qmake, Autotools และย้ายไปที่ CMake จนถึงตอนนี้ฉันสามารถคาดหวังได้อย่างชัดเจนว่าโครงการที่ใช้ CMake จะตกอยู่ในสถานการณ์การคอมไพล์หรือบนการตั้งค่า VisualStudio หรือเพียงแค่ต้องทำความสะอาดเล็กน้อยเพราะโครงการไม่ได้มีเฉพาะส่วน Windows หรือ OSX เท่านั้น ไปยัง codebase ฉันไม่สามารถคาดหวังจริงๆจาก scons ที่ตามโครงงานและผมคาดหวังอย่างเต็มที่ 1/3 หรือมากกว่าโครงการ Autotools ที่จะได้รับบางสิ่งบางอย่างที่ไม่ถูกต้องที่ติ๊ดมันสร้างที่เหมาะสมกับบริบทใด ๆ ยกเว้นโฮสต์อาคารหนึ่งหรือ Scratchbox2 หนึ่ง

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

12

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

— Rob11311

9

สิ่งที่มันไม่ได้เบี่ยงเบนไปจากมันเลย ด้วย Autotools คุณกำลังกังวลเกี่ยวกับการชดเชยสิ่งต่าง ๆ เช่นนั้นการใช้งานซ้ำเหล่านั้นเป็นการขยายความคิดอย่างมาก ยกระดับไปอีกขั้นเหมือนเดิม คุณควรดูจากฉากหลังนั้น ... ณ จุดนี้มันไม่ได้เบี่ยงเบนไปจากทั้งหมด คุณไม่ได้ระบุสาเหตุที่แท้จริงในการให้เหตุผลของคุณ - เกิดอะไรขึ้น ฉันกำลังใช้นิ้วคิดอย่างถูกต้องซึ่งนำไปสู่สิ่งนั้นพร้อมกับ Shellshock และคนอื่น ๆ ที่ชอบมัน ถ้ามันพังคุณควรแก้ไขมัน ถ้าคุณทำไม่ได้คุณควรถามว่าทำไมทำต่อไป

— Svartalf

5

ฉันไม่สงสัยเลยว่า autotools และ scons ดูด แต่คำตอบนี้ทำงานได้ไม่ดีเมื่อสังเกตเห็นข้อเสียของ CMake (ระบบการสร้างที่ฉันต้องการเพียงเพราะสถานะการสร้างระบบที่น่าเศร้ามาก) โดยทั่วไป CMake เป็นเศษส่วนของความไม่สอดคล้องกับการรองรับในตัวสำหรับเคสแบบขอบแต่ละอันแทนที่จะเป็นนามธรรมหลักที่จัดการสิ่งต่าง ๆ ส่วนใหญ่ มันแน่นอนเทปพันสายไฟและลวดประกันการเขียนโปรแกรม ฉันแน่ใจว่าฉันทำอะไรผิด แต่ไม่รองรับ VisualStudio เว้นแต่คุณจะพบโครงการ VS ต่อ CMakeLists.txt ที่ยอมรับได้ (ฉันไม่ใช่ผู้ใช้ VS แต่ Winfriends ของฉันบอกฉันว่ามันไม่ดี)

— weberc2

5

ซึ่งแตกต่างจากคนอื่น ๆ เกลียดเครื่องมือการเขียนโปรแกรมที่มีอยู่ไม่เพียงพอวัสดุที่จะทำให้หนังสือที่เรียกว่า "CMake, ส่วนที่ดี" (อาจจะเป็นหนังสือเล่มเล็ก ๆ หรือโพสต์บล็อก) และมันมากขึ้นของเศษส่วนของการออกแบบที่ไม่ดีกว่าPHP

— weberc2

2

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

— weberc2

73

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

ผู้ใช้ส่วนใหญ่ไม่จำเป็นต้องติดตั้งระบบอัตโนมัติในกล่อง ในอดีตมีความสับสนเกิดขึ้นเนื่องจากนักพัฒนาซอฟต์แวร์จำนวนมากแจกจ่าย tarballs ที่มีรูปแบบไม่ถูกต้องซึ่งบังคับให้ผู้ใช้เรียกใช้ autoconf เพื่อสร้างสคริปต์การกำหนดค่าใหม่และนี่เป็นข้อผิดพลาดของบรรจุภัณฑ์ ความสับสนที่เพิ่มขึ้นนั้นเกิดจากความจริงที่ว่าการแจกแจงลินุกซ์ที่สำคัญส่วนใหญ่ติดตั้ง autotools หลายรุ่นเมื่อพวกเขาไม่ควรติดตั้งใด ๆ ของพวกเขาโดยค่าเริ่มต้น ความสับสนที่มากขึ้นนั้นเกิดจากนักพัฒนาที่พยายามใช้ระบบควบคุมเวอร์ชัน (เช่น cvs, git, svn) เพื่อแจกจ่ายซอฟต์แวร์ของพวกเขาแทนที่จะสร้าง tarballs

— วิลเลียม Pursell
แหล่งที่มา

5

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

— d -_- b

5

@ ประตูฉันไม่เข้าใจคำถามของคุณ โครงการทั้งหมดที่ฉันทำงานเกี่ยวกับการผลิต tarball ซึ่งแตกต่างจากการชำระเงิน VCS การรักษาความช่วยเหลือที่แตกต่างกันสองแบบด้วยการกระจายที่เชื่อถือได้

— วิลเลียม Pursell

13

มันเป็นความจริงที่โครงการจำนวนมากขอให้ผู้คนใช้ VCS เพื่อรับรุ่นล่าสุด แต่มันก็เหมาะสำหรับนักพัฒนาเท่านั้น น่าเสียดายที่ผู้ใช้หลายคนไม่เข้าใจความแตกต่างระหว่าง tarball ที่วางจำหน่ายและ VCS ความพยายามในการสร้างจาก VCS กำหนดการอ้างอิงเพิ่มเติม ผู้ใช้อาจต้องการasciidocหรือhelp2manหรือdoxygenหรือที่สำคัญชุดค่าผสมอัตโนมัติที่ถูกต้อง นี่เป็นปัญหาด้านการตลาดอย่างมากสำหรับเครื่องมืออัตโนมัติ ผู้ใช้คิดผิดว่าพวกเขาต้องการติดตั้ง autoconf เพราะพวกเขาไม่เข้าใจความแตกต่างระหว่าง tarball และ VCS

— วิลเลียม Pursell

3

เหตุใดโครงการจึงไม่สามารถกระจายเอาท์พุทไฟล์โครงการและ Makefiles ของ Cmake สำหรับแพลตฟอร์มทั่วไปได้เช่น Win, Linux และ MacOSX ดูเหมือนว่าสถานการณ์เช่นเดียวกับเครื่องมือ lex / yacc คุณรวมรหัส C genarated เพื่อให้สามารถสร้างบนแพลตฟอร์มโดยไม่ต้องใช้เครื่องมือ

— Rob11311

3

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

— lanoxx

24

มันไม่เกี่ยวกับมาตรฐานการเข้ารหัสของ GNU

ประโยชน์ปัจจุบันของเครื่องมืออัตโนมัติ - โดยเฉพาะเมื่อใช้กับ automake คือการรวมเข้ากับการสร้างการกระจาย Linux ได้ดีมาก

ด้วย cmake เป็นต้นมันคือ "เคยเป็น -DCMAKE_CFLAGS หรือ -DCMAKE_C_FLAGS ที่ฉันต้องการหรือไม่" ไม่มันไม่ใช่ "-DCMAKE_C_FLAGS_RELEASE" หรือ -DCMAKE_C_FLAGS_DEBUG มันสับสน - ใน autoconf เป็นเพียง. / config CFLAGS = "- O0 -ggdb3" และคุณมีมัน

ในการบูรณาการกับการสร้างโครงสร้างพื้นฐาน scons มีปัญหาที่คุณไม่สามารถใช้make %{?_smp_mflags}, _smp_mflagsในกรณีนี้เป็นแมโคร RPM ว่าประมาณขยาย (ผู้ดูแลระบบสามารถกำหนดได้) ระบบไฟฟ้า คนใส่สิ่งต่าง ๆ เช่น -jNCPUS ที่นี่ผ่านสภาพแวดล้อม ด้วยสคอนที่ไม่ทำงานดังนั้นแพ็กเกจที่ใช้สก็อตอาจได้รับซีเรียลต่อเนื่องในตัวเท่านั้น

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

8

+1 และโลกน่าจะดีกว่านี้ถ้าเรื่องจริง น่าเศร้าที่ ./configure CFLAGS=-O0ล้มเหลวบ่อยครั้งด้วยแพ็คเกจที่เขียนทับ CFLAGS ใน makefile และต้องการให้ผู้ใช้รัน./configure --enable-debugแทน (เช่นtmux)

— William Pursell

2

มันไม่ได้สับสนอะไรมากไปกว่า Autotools และเมื่อวิลเลียมชี้ให้เห็นอย่างถูกต้องมันก็ถูกจับไปสู่นรกด้วย CFLAGS = "<foo>" ในเฟรมที่ไม่ถูกต้อง ค่อนข้างง่ายนี่เป็นอีกหนึ่งในรายการ "เห็นเก่า" และตัวอย่างของ CMake เป็นของปลอม ... อีกครั้ง ... คุณสามารถทำสิ่งแรกได้หากคุณไม่ได้ระบุ RELEASE หรือ DEBUG ล้มเหลว.

— Svartalf

17

สิ่งสำคัญที่ต้องรู้เกี่ยวกับ Autotools คือพวกเขาไม่ใช่ระบบสร้างทั่วไป - พวกเขาใช้มาตรฐานการเข้ารหัสของ GNU และไม่มีอะไรอื่น หากคุณต้องการสร้างแพ็คเกจที่เป็นไปตามมาตรฐาน GNU ทั้งหมด Autotools เป็นเครื่องมือที่ยอดเยี่ยมสำหรับงาน หากคุณไม่ทำเช่นนั้นคุณควรใช้ Scons หรือ CMake (ตัวอย่างเช่นดูคำถามนี้) ความเข้าใจผิดที่พบบ่อยนี้เป็นที่มาของความคับข้องใจกับ Autotools ส่วนใหญ่มาจาก

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

11

มาตรฐาน GNU สามารถใช้งานใน Automake กับในของคุณAUTOMAKE_OPTIONS = -foreign Makefile.am(หรือ-foreignในของคุณautogen.shฉันคิดว่าเกือบทุกคนใช้สิ่งนี้)

— Dietrich Epp

9

ใช่ แต่เพียงควบคุมว่า Automake บังคับใช้กฎ GNU ผิวเผินเช่นเดียวกับไฟล์ README ที่ต้องการหรือไม่ มันไม่ได้มีการเปลี่ยนแปลงขั้นพื้นฐานของการสร้าง tarball GNU สไตล์กับกฎเหมือนและinstallcheck distcleanหากคุณพยายามที่จะเปลี่ยนพฤติกรรมแบบนั้นในขณะที่ยังใช้ Autotools อยู่แสดงว่าคุณกำลังเสียเวลา

— ptomato

1

พวกเขา (ในทางทฤษฎี) อนุญาตให้สร้างและติดตั้งชุดซอฟต์แวร์ทั้งหมดด้วยวิธีเดียวกัน

— ptomato

ตามทฤษฎีแล้วอนุญาตให้คุณจัดการกับคอมไพเลอร์ BROKEN และระบบปฏิบัติการได้อย่างเหมาะสมกว่าเครื่องมืออื่น ๆ และใช้กฎผิวเผินเช่น @ptomato ที่ไฮไลต์อยู่ที่นั่น หากคุณกำลังใช้เครื่องมือที่ทันสมัย (เช่น GCC หรือเสียงดัง ... สำหรับตัวอย่าง) เครื่องมือบนระบบปฏิบัติการที่ทันสมัยโดยไม่มีอะไรที่ผิดพลาดจริง ๆ พูด Linux หรือ * BSD ปัจจุบันคุณไม่จำเป็นต้องมี "กฎ" ที่นั่น ที่จริงแล้วพวกเขาทำงานให้คุณมากขึ้นและไม่สามารถช่วยได้จริงๆสำหรับการรวบรวมข้ามสายงาน เกือบครึ่งหนึ่งของการใช้งานทั้งหมดในวันนี้ใช้สำหรับ Linux และ * BSD ทำไมคุณถึงไปกับสิ่งที่ไม่สามารถช่วยคุณได้?

— Svartalf

ไม่แน่ใจว่าทำไมคุณถึงลงคะแนนคำตอบเนื่องจากคุณดูเหมือนจะรับทราบในความคิดเห็นของคุณ ... ?

— ptomato

9

ในขณะที่จากมุมมองของนักพัฒนา CMake เป็นเครื่องมือที่ใช้งานง่ายที่สุดในขณะนี้จากมุมมองของผู้ใช้ autotools มีข้อดีอย่างหนึ่ง

autotools สร้างไฟล์เดียวกำหนดค่าสคริปต์และไฟล์ทั้งหมดเพื่อสร้างมันมาพร้อมกับการกระจาย มันง่ายต่อการเข้าใจและแก้ไขด้วยความช่วยเหลือของ grep / sed / awk / vi เปรียบเทียบสิ่งนี้กับ Cmake ที่พบไฟล์จำนวนมากใน / usr / share / cmak * / Modules ซึ่งผู้ใช้ไม่สามารถแก้ไขได้เว้นแต่เขาจะมีสิทธิ์การเข้าถึงระดับผู้ดูแลระบบ

ดังนั้นหากบางสิ่งบางอย่างใช้งานไม่ได้ก็มักจะ "แก้ไข" ได้ง่ายโดยใช้เครื่องมือ Standard Unix (grep / sed / awk / vi ฯลฯ ) ในแบบค้อนขนาดใหญ่โดยไม่ต้องเข้าใจระบบ builds

คุณเคยขุดไดเรกทอรีสร้าง cmake ของคุณเพื่อค้นหาว่ามีอะไรผิดปกติหรือไม่? เมื่อเทียบกับ shellscript อย่างง่ายซึ่งสามารถอ่านได้จากบนลงล่างตามไฟล์ Cmake ที่สร้างขึ้นเพื่อค้นหาว่าเกิดอะไรขึ้นเป็นเรื่องยาก นอกจากนี้เมื่อใช้ CMake การปรับไฟล์ FindFoo.cmake ไม่เพียง แต่ต้องมีความรู้เกี่ยวกับภาษา CMake เท่านั้น แต่ยังอาจต้องใช้สิทธิ์ผู้ใช้ขั้นสูงอีกด้วย

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

7

ฉันไม่คิดว่ามีปัญหากับ Autotools เป็น "แก้ไขได้อย่างง่ายดาย" ในการเปรียบเทียบกับ CMake ...

— sleske

7

เพราะ autotools เป็นระบบที่ซับซ้อน (เช่นเดียวกับ CMake) หากคุณคิดว่า Autotools "แก้ไขได้ง่าย" (อาจมีเหตุผลที่จะคิดสิ่งนี้) มันจะเป็นการดีที่ IMHO จะอธิบายคำตอบในสิ่งที่ปัญหาง่ายต่อการแก้ไข

— sleske

5

autotools สร้างไฟล์เดียวกำหนดค่าสคริปต์และไฟล์ทั้งหมดเพื่อสร้างมันมาพร้อมกับการกระจาย มันง่ายต่อการเข้าใจและแก้ไขด้วยความช่วยเหลือของ grep / sed / awk / vi เปรียบเทียบสิ่งนี้กับ Cmake ที่พบไฟล์จำนวนมากใน / usr / share / cmak * / Modules ซึ่งผู้ใช้ไม่สามารถแก้ไขได้เว้นแต่เขาจะมีสิทธิ์การเข้าถึงระดับผู้ดูแลระบบ คุณเคยขุดไดเรกทอรีสร้าง cmake ของคุณเพื่อค้นหาว่ามีอะไรผิดปกติหรือไม่? เมื่อเปรียบเทียบกับ shellscript แบบง่าย ๆ ซึ่งสามารถอ่านได้จากบนลงล่างตามไฟล์ Cmake ที่สร้างขึ้นมาเพื่อค้นหาว่าเกิดอะไรขึ้นเป็นเรื่องยาก

— arve

2

ใช่ที่ทำให้รู้สึกขอบคุณ ฉันเอาเสรีภาพเพิ่มไปยังคำตอบของคุณ อย่าลังเลที่จะเปลี่ยนกลับ :-)

— sleske

1

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

— James Moore