automake และ autoconf เป็นวิธีมาตรฐานในการรวบรวมรหัสหรือไม่


22

บางครั้งฉันรวบรวมแอพจากแหล่งที่มาและฉันก็ใช้:

./configure
make
sudo make install

แต่เมื่อเร็ว ๆ นี้ฉันได้พบกับ./autogen.shสิ่งที่สร้างการกำหนดค่าและสร้างสคริปต์ให้ฉันและรันพวกเขา

มีวิธีอื่นใดในการเพิ่มประสิทธิภาพการรวบรวม C / C ++ / C # (โมโน) ทำให้ดูเหมือนว่าจะเก่าไปหน่อย มีเครื่องมือใหม่ ๆ บ้างไหม? ได้รับตัวเลือกฉันควรใช้อันไหน


ไม่มีอะไรที่เหมือนกับ 'รหัส' ตัวอย่างเช่นถ้าคุณได้รับรหัส Java คุณอาจจะสร้างมันโดยใช้ maven หรือ ant ถ้าคุณได้รับ Python ตัวเลือกที่ดีคือ setuptools ไม่มีวิธีมาตรฐานในการรวบรวมอะไร บางทีคุณควรกำหนดคำถามใหม่
diega

จุดดี. ฉันเขียนโค้ดด้วย C # กับโมโนจริงๆ แต่คำถามของฉันใช้ได้กับ C / C ++ เช่นกัน
Louis Salin

บันทึกย่อขนาดเล็ก: autogen.sh ไม่ได้ดำเนินการสร้างให้คุณเพียงแค่กำหนดค่า
Sandy

@Sandy autogen.shส่วนใหญ่จะเป็นสคริปต์ที่กำหนดเองที่มักจะวิงวอนautoreconfแต่ยังอาจก่อให้เกิดและแม้กระทั่ง./configure makeฉันไม่คิดว่าพฤติกรรมของมันจะเป็นมาตรฐาน แต่อย่างใด วัตถุประสงค์หลักคือในการมีไฟล์ exetable ภายในโครงการซึ่งผู้คนสามารถเรียกใช้ (แทนที่จะต้องรู้ว่าพวกเขาจำเป็นต้องคิดในใจautoreconf)
umläute

คำตอบ:


42

Autoconf และ Automake ถูกจัดทำขึ้นเพื่อแก้ปัญหาวิวัฒนาการของ Unix

เมื่อ Unix พัฒนาไปในทิศทางที่ต่างกันนักพัฒนาที่ต้องการโค้ดพกพามักจะเขียนโค้ดดังนี้:

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

เนื่องจาก Unix ถูกนำไปใช้ในการใช้งานที่แตกต่างกัน (BSD, SystemV, ผู้จำหน่ายหลายรายและต่อมา Linux และ Unix-like system อื่น ๆ ) มันกลายเป็นเรื่องสำคัญสำหรับนักพัฒนาที่ต้องการเขียนโค้ดพกพาเพื่อเขียนโค้ดที่ไม่ขึ้นอยู่กับยี่ห้อ แต่ขึ้นอยู่กับฟีเจอร์ที่เปิดเผยโดยระบบปฏิบัติการ สิ่งนี้มีความสำคัญเนื่องจากเวอร์ชันของ Unix จะแนะนำคุณสมบัติใหม่เช่นการเรียกใช้ระบบ "ส่ง" และระบบปฏิบัติการอื่น ๆ จะใช้งานในภายหลัง แทนที่จะมีสปาเก็ตตี้ของรหัสที่ตรวจสอบแบรนด์และรุ่นต่างๆนักพัฒนาเริ่มตรวจสอบคุณสมบัติโดยใช้รหัสจึงกลายเป็น:

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

ไฟล์ README ส่วนใหญ่เพื่อคอมไพล์ซอร์สโค้ดย้อนกลับไปในนักพัฒนาซอฟต์แวร์ยุค 90 เพื่อแก้ไขไฟล์ config.h และแสดงความคิดเห็นว่าคุณสมบัติที่เหมาะสมที่มีอยู่ในระบบหรือจะจัดส่งไฟล์ config.h มาตรฐานสำหรับการกำหนดค่าระบบปฏิบัติการแต่ละรายการที่ผ่านการทดสอบแล้ว

กระบวนการนี้มีทั้งความยุ่งยากและเกิดข้อผิดพลาดและนี่คือสิ่งที่ Autoconf เกิดขึ้น คุณควรคิดถึง Autoconf เป็นภาษาที่สร้างขึ้นจากคำสั่งเชลล์ด้วยมาโครพิเศษที่สามารถแทนที่กระบวนการแก้ไขที่เป็นมนุษย์ของ config.h ด้วยเครื่องมือที่ตรวจสอบระบบปฏิบัติการสำหรับการทำงาน

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

ดังนั้นเมื่อคุณเรียกใช้./configure && makeคุณกำลังตรวจสอบคุณสมบัติที่มีอยู่ในระบบของคุณแล้วสร้างไฟล์ปฏิบัติการที่มีการกำหนดค่าที่ตรวจพบ

เมื่อโครงการโอเพ่นซอร์สเริ่มต้นโดยใช้ระบบควบคุมซอร์สโค้ดมันสมเหตุสมผลที่จะตรวจสอบในไฟล์ configure.ac แต่ไม่ใช่ผลลัพธ์ของการคอมไพล์ (กำหนดค่า) autogen.sh เป็นเพียงสคริปต์ขนาดเล็กที่เรียกใช้คอมไพเลอร์ autoconf ด้วยอาร์กิวเมนต์คำสั่งที่เหมาะสมสำหรับคุณ

-

Automake เติบโตขึ้นจากการปฏิบัติที่มีอยู่ในชุมชน โครงการ GNU สร้างมาตรฐานให้กับชุดเป้าหมายปกติสำหรับ Makefiles:

  • make all จะสร้างโครงการ
  • make clean จะลบไฟล์ที่รวบรวมทั้งหมดจากโครงการ
  • make install จะติดตั้งซอฟต์แวร์
  • สิ่งที่ต้องการmake distและmake distcheckจะเตรียมซอร์สสำหรับการแจกจ่ายและตรวจสอบว่าผลลัพธ์นั้นเป็นซอร์สโค้ดแพคเกจที่สมบูรณ์
  • และอื่น ๆ ...

การสร้าง makefiles ที่สอดคล้องกับการใช้งานนั้นเป็นภาระเพราะมีจำนวนมากที่ซ้ำกันซ้ำแล้วซ้ำอีก ดังนั้น Automake เป็นคอมไพเลอร์ใหม่ที่รวมเข้ากับ autoconf และประมวลผล "แหล่งที่มา" Makefile's (ชื่อ Makefile.am) ลงใน Makefiles ที่สามารถป้อนให้กับ Autoconf ได้

ห่วงโซ่อัตโนมัติ automake / autoconf ใช้เครื่องมือช่วยเหลืออื่น ๆ เป็นจำนวนมากและมีการเพิ่มส่วนประกอบอื่น ๆ สำหรับงานเฉพาะอื่น ๆ เมื่อความซับซ้อนของการรันคำสั่งเหล่านี้ตามลำดับเพิ่มขึ้นความต้องการสคริปต์พร้อมใช้จึงเกิดขึ้นและนี่คือที่มาของ autogen.sh

เท่าที่ฉันรู้ Gnome เป็นโครงการที่แนะนำการใช้สคริปต์ผู้ช่วยนี้


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

14

มี "ผู้เล่นที่ยิ่งใหญ่" สองคนในพื้นที่นี้ Cmake และ GNU Autotools

  • GNU Autotools เป็นวิธี GNU ในการทำสิ่งต่าง ๆ และให้ความสำคัญกับ * ระวัง มันเป็นระบบ meta-build ที่จัดทำชุดเครื่องมือที่สร้างการกำหนดค่าเฉพาะและสร้างไฟล์สำหรับสิ่งที่คุณกำลังพยายามทำ สิ่งนี้จะช่วยให้คุณทำการเปลี่ยนแปลงเพิ่มเติมในโค้ดของคุณโดยไม่ต้องจัดการระบบ build ของคุณโดยตรงและช่วยให้ผู้อื่นสร้างโค้ดของคุณในแบบที่คุณไม่ได้ออกแบบมาสำหรับ - ภายใต้ * nix

  • Cmake เป็นวิธีข้ามแพลตฟอร์มในการทำสิ่งต่าง ๆ ทีม Cmake สร้างซอฟต์แวร์ในหลาย ๆ วิธีด้วย GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux ไม่ว่าอะไรก็ตาม หากคุณกังวลเกี่ยวกับการพกพาของรหัสฐานของคุณนี่เป็นวิธีที่จะไป

ตามที่ได้รับการกล่าวถึงบางคนดูเหมือนจะชอบ Scons หากคุณคุ้นเคยกับ Python สิ่งนี้อาจช่วยเพิ่มความสอดคล้องในสภาพแวดล้อมการทำงานของคุณ

Ruby ยังมีระบบ meta-build ที่เรียกว่า Rake ซึ่งค่อนข้างเท่ห์ในตัวของมันเองและมีประโยชน์มากสำหรับผู้ที่คุ้นเคยกับ Ruby อยู่แล้ว


6

Sconsเป็นสิ่งที่สามารถทดแทนได้แม้ว่าฉันจะไม่มีประสบการณ์ส่วนตัว มันยังนำมาใช้ใน Python ซึ่งอาจเป็นปัญหาขึ้นอยู่กับสภาพแวดล้อมการสร้าง


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

3

หากคุณใช้ C # / Mono คุณสามารถใช้ msbuild (ไฟล์. sln / .csproj ที่ MonoDevelop และ Visual Studio ใช้) เพื่อจัดการกระบวนการสร้างทั้งหมดของคุณ

จากนั้นคุณสามารถสร้างจาก MonoDevelop หรือเรียกใช้xbuildคำสั่งในเทอร์มินัลที่คุณชื่นชอบ (ทำงานได้ดีที่สุดใน Mono> = 2.6) มันง่ายมากและไม่ต้องใช้ชิ้นส่วนใดเลยเพราะ MonoDevelop จะจัดการไฟล์ msbuild ให้กับคุณและคุณไม่จำเป็นต้องแก้ไขไฟล์เว้นแต่ว่าคุณต้องการปรับแต่งสิ่งต่าง ๆ ที่ UI ของ MonoDevelop สามารถทำได้

ฉันไม่คุ้นเคยกับวิธีที่ผู้คนพึ่งพา msbuild จัดการกับการติดตั้งสำหรับโครงการของพวกเขา แต่คุณสามารถถามได้ตลอดเวลา ;-)


ใช่ฉันรู้เกี่ยวกับ xbuild แต่ฉันพยายามหย่านมตัวเองจาก IDEs ที่ต้องการจับมือฉัน ยิ่งกว่านั้น Mono ถูกคอมไพล์โดยใช้ Mono และใช้ autoconf ดังนั้นฉันจึงต้องการทราบอีกเล็กน้อย ขอบคุณ!
Louis Salin

1
ที่น่าสนใจคือโครงการโมโนจำนวนมากกำลังพยายามโยกย้ายไปยัง msbuild ในขณะนี้ xbuild ทำงานได้ดี ทำให้ Windows / Mac รองรับได้ง่ายขึ้นเล็กน้อย โมโนมีรหัส C มากมายที่ฉันไม่แน่ใจว่ามันจะเป็นไปได้จริงสำหรับพวกเขาที่จะย้ายไปที่ xbuild แต่ autoconf ใช้งานได้ดีดังนั้นทำทุกอย่างเพื่อคุณ :-)
Sandy

0

สำหรับ C # คุณสามารถใช้ xbuild (และ msbuild บน windows) ซึ่งจะสร้างโครงการจากไฟล์โครงการของคุณ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.