ทำไมต้อง. / กำหนดค่า; ทำให้; ทำการติดตั้ง เป็น 3 ขั้นตอนแยกกัน?

118

ทุกครั้งที่คุณรวบรวมข้อมูลจากแหล่งที่มาคุณจะต้องทำตาม 3 ขั้นตอนเดียวกัน:

$ ./configure
$ make
$ make install

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

#!/bin/sh
./configure
make
make install

ทำไมคนถึงทำ 3 ขั้นตอนแยกกัน?

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

2

หากระบบบิลด์เขียนถูกต้อง - และโดยปกติแล้วจะเป็น - คุณสามารถข้ามขั้นตอนที่สองได้

— Reinierpost

คำถามของคุณไม่โง่ คุณสามารถสร้างโปรแกรมของคุณในสภาพแวดล้อม Linux และหลังจากนั้นคุณสามารถใช้โดยแอปพลิเคชันการจำลองเสมือนบางตัวหรือคุณสามารถสร้างโดยตรงในสภาพแวดล้อม windows โดยใช้ mingw

— Mihai8

121

เพราะแต่ละขั้นตอนทำไม่เหมือนกัน

จัดเตรียม (ตั้งค่า) สภาพแวดล้อมสำหรับการสร้าง

./configure

สคริปต์นี้มีตัวเลือกมากมายที่คุณควรเปลี่ยน กดไลค์--prefixหรือ--with-dir=/foo. นั่นหมายความว่าทุกระบบมีการกำหนดค่าที่แตกต่างกัน นอกจากนี้ยังมี./configureการตรวจสอบสำหรับห้องสมุดที่หายไปว่าควรจะติดตั้ง มีอะไรผิดพลาดที่นี่ทำให้ไม่สามารถสร้างแอปพลิเคชันของคุณได้ นั่นเป็นเหตุผลที่ distros มีแพ็กเกจที่ติดตั้งในที่ต่างๆเนื่องจากทุก distro คิดว่าการติดตั้งไลบรารีและไฟล์บางไฟล์ลงในไดเร็กทอรีบางอย่างจะดีกว่า ว่ากันว่าวิ่ง./configureแต่อันที่จริงคุณควรเปลี่ยนเสมอ

ตัวอย่างเช่นมีลักษณะที่เว็บไซต์แพคเกจ Arch ลินุกซ์ ที่นี่คุณจะเห็นว่าแพ็คเกจใด ๆ ใช้พารามิเตอร์กำหนดค่าที่แตกต่างกัน (สมมติว่าพวกเขากำลังใช้เครื่องมืออัตโนมัติสำหรับระบบบิลด์)

การสร้างระบบ

make

นี่เป็นmake allค่าเริ่มต้นจริงๆ และทุกการทำมีการกระทำที่แตกต่างกันไป บางคนทำการสร้างบางคนทำการทดสอบหลังการสร้างบางคนชำระเงินจากที่เก็บ SCM ภายนอก โดยปกติคุณไม่จำเป็นต้องให้พารามิเตอร์ใด ๆ แต่อีกครั้งบางแพ็คเกจจะดำเนินการต่างกัน

ติดตั้งเข้ากับระบบ

make install

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

ตอนนี้คุณเห็นแล้วว่าแต่ละขั้นตอนเป็นข้อกำหนดเบื้องต้นสำหรับขั้นตอนต่อไป แต่ละขั้นตอนคือการเตรียมการที่จะทำให้สิ่งต่างๆดำเนินไปอย่างลื่นไหลไร้ปัญหา Distros ใช้อุปมานี้เพื่อสร้างแพ็คเกจ (เช่น RPM, deb ฯลฯ )

คุณจะเห็นว่าแต่ละขั้นตอนเป็นสถานะที่แตกต่างกัน นั่นเป็นเหตุผลที่ผู้จัดการแพ็คเกจมีเครื่องห่อที่แตกต่างกัน ด้านล่างนี้เป็นตัวอย่างของ Wrapper ที่ให้คุณสร้างแพ็คเกจทั้งหมดได้ในขั้นตอนเดียว แต่จำไว้ว่าแต่ละแอปพลิเคชันมี Wrapper ที่แตกต่างกัน (จริงๆแล้ว Wrapper เหล่านี้มีชื่อเช่น spec, PKGBUILD เป็นต้น):

def setup:
... #use ./configure if autotools is used

def build:
... #use make if autotools is used

def install:
... #use make all if autotools is used

นี่คือหนึ่งสามารถใช้ autotools นั่นหมายความว่า./configure, และmake make installแต่อีกอันหนึ่งสามารถใช้ SCons การตั้งค่าที่เกี่ยวข้องกับ Python หรือสิ่งที่แตกต่างออกไป

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

— Fatih Arslan
แหล่งที่มา

23

อ่านสิ่งนี้อีกครั้งประมาณหนึ่งปีต่อมาฉันต้องเพิ่มว่าทุกอย่างสมเหตุสมผลและยังคงมีการเรียกคำสั่งเดียวที่ทำทั้ง 3 ขั้นตอนด้วยการกำหนดค่าเริ่มต้น พวกเขาทั้งหมดมีการกำหนดค่าเริ่มต้นเป็นอย่างอื่นคุณไม่สามารถเรียกมันโดยไม่มีข้อโต้แย้งได้

— erikbwork

บางครั้งฉันสามารถทำการติดตั้งโดยไม่ต้องทำ สิ่งนี้หมายความว่า? หากฉันข้ามการสร้างฉันสามารถทำการติดตั้งได้หรือไม่

— CMCDragonkai

3

installขึ้นอยู่กับallจึงmake installจะเรียกmake all

คำตอบที่ยอดเยี่ยม แต่ฉันไม่เข้าใจว่าทำไมบางครั้งต้องทำการติดตั้งและบางครั้งก็ไม่ (การสร้างเพียงครั้งเดียวทำทุกอย่าง)

— HanniBaL90

make installเพียงแค่ติดตั้งทรัพยากรต่างๆไปยังตำแหน่งที่กำหนดไว้ล่วงหน้า หากคุณสนใจเฉพาะไฟล์ปฏิบัติการคุณสามารถใช้ไฟล์ปฏิบัติการจากไดเร็กทอรี build และเพิ่ม build dir ใน PATH ของคุณ

— jdhao

31

ประการแรกควรเป็น./configure && make && make installเพราะแต่ละอย่างขึ้นอยู่กับความสำเร็จของอดีต เหตุผลส่วนหนึ่งคือวิวัฒนาการและส่วนหนึ่งของเหตุผลคือความสะดวกสบายสำหรับขั้นตอนการพัฒนา

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

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

กรณีเดียวที่คำสั่งสามคำสั่งทำงานในแถวคือเมื่อผู้ใช้ติดตั้งโปรแกรมหรือสร้างแพ็คเกจ (เช่น Debian's debuild หรือ rpmbuild ของ RedHat) และนั่นถือว่าแพคเกจสามารถให้เป็นแบบธรรมดาconfigureซึ่งโดยปกติแล้วไม่ใช่กรณีสำหรับบรรจุภัณฑ์ที่อย่างน้อย--prefix=/usrก็เป็นที่ต้องการ และ pacakgers ก็ต้องการที่จะจัดการกับรากปลอมเมื่อทำmake installส่วน เนื่องจากมีข้อยกเว้นมากมายการทำ./configure && make && make installกฎจึงไม่สะดวกสำหรับผู้คนจำนวนมากที่ทำตามขั้นตอนบ่อยกว่ามาก!

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

2

ขอบคุณสำหรับคำแนะนำ&&!

— erikbwork

4

ประการแรก. / กำหนดค่าไม่พบทุกสิ่งที่ต้องการเสมอไปหรือในกรณีอื่น ๆ จะพบทุกสิ่งที่ต้องการ แต่ไม่ใช่ทุกสิ่งที่สามารถใช้ได้ ในกรณีนี้คุณต้องการทราบเกี่ยวกับเรื่องนี้ (และสคริปต์. / install.sh ของคุณก็จะล้มเหลวอยู่ดี!) สิ่งเหล่านี้จะใช้ไลบรารีหากมีให้ใช้งาน แต่จะคอมไพล์ต่อไปหากไม่มีโดยจะปิดใช้งานบางตัวเลือก ปัญหาคือจากนั้นคุณจะพบในภายหลังว่าคอมไพล์โดยไม่รองรับบางรูปแบบหรืออย่างอื่นทำให้คุณต้องย้อนกลับไปทำซ้ำ

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

กระจายเฉพาะมักจะให้สคริปที่มีประสิทธิภาพการทำงานนี้ ./install.sh ในลักษณะการจัดจำหน่ายที่มีความอ่อนไหว - ตัวอย่างเช่นRPMs แหล่งข้อมูลจำเพาะ + ไฟล์ + rpmbuildหรือslackbuilds

(เชิงอรรถ: ดังที่กล่าวมาฉันยอมรับว่า. / กำหนดค่า; สร้าง; ทำการติดตั้งอาจเป็นเรื่องที่น่าเบื่อมาก)

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

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

— erikbwork

3

จริง แต่แล้วทำไมต้องมีไฟล์? เพียงแค่ใช้นามแฝง (แม้ว่าคุณจะต้องคิดชื่อที่ดีกว่า / สั้นกว่า "confmakeins" แต่วันนี้ฉันไม่ได้รับแรงบันดาลใจ!) นามแฝง confmakeins = '. / กำหนดค่า && make && sudo ทำการติดตั้ง'; ไดเร็กทอรีแหล่งซีดี confmakeins;

— Soz

ฟังดูเข้าท่า. ฉันไม่เคยเขียนนามแฝงด้วยตัวเองดังนั้นฉันจึงไม่ได้คิดถึงมัน!

— erikbwork

3

configure อาจล้มเหลวหากพบว่าการอ้างอิงขาดหายไป

makeเรียกใช้เป้าหมายเริ่มต้นซึ่งเป็นเป้าหมายแรกที่แสดงรายการใน Makefile บ่อยครั้งที่เป้าหมายนี้เป็นallแต่ไม่เสมอไป คุณจะทำได้ก็ต่อmake all installเมื่อคุณรู้ว่านั่นคือเป้าหมาย

ดังนั้น ...

#!/bin/sh

if ./configure $*; then
  if make; then
    make install
  fi
fi

หรือ:

./configure $* && ./make && ./make install

$*รวมอยู่เพราะมักจะมีที่จะให้ตัวเลือกในการconfigureรวมอยู่เพราะมักจะมีที่จะให้ตัวเลือกในการ

แต่ทำไมไม่ปล่อยให้คนทำเอง? นี่คือชัยชนะที่ยิ่งใหญ่จริงๆหรือ?

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

1

ไม่ใช่เรื่องสำคัญร้ายแรง แต่มันเกี่ยวกับสิ่งที่เราโปรแกรมเมอร์ทำนั่นคือการทำให้คอมพิวเตอร์ทำงานซ้ำ ๆ ให้เรา ขวา?

— erikbwork

1

อืม ... configureเป็นส่วนหนึ่งของชุดเครื่องมือ GNU Automake ซึ่งเป็นประเภทของ add-on ที่จะทำให้ Make มีมาหลายปีแล้วและทำงานได้ดี ที่กล่าวว่าผู้คนได้คิดวิธีอื่น ๆ ในการจัดการกระบวนการผลิต Ant และ cmake มีลูกน้อง แต่ส่วนต่างๆของกระบวนการสร้าง (เช่นการกำหนดค่าการสร้างและการติดตั้ง) ยังคงเป็นคำสั่งแยกกันทั้งหมด

— ghoti