เหตุใดจึงไม่มีระบบการจัดการแพ็คเกจสำหรับ C และ C ++ [ปิด]

มีภาษาการเขียนโปรแกรมบางอย่างซึ่งมีอยู่ในระบบการจัดการบรรจุภัณฑ์:

• CTANสำหรับ TeX
• CPANสำหรับ Perl
• Pip & Eggsสำหรับ Python
• Mavenสำหรับ Java
• พันธมิตรสำหรับ Haskell
• อัญมณีสำหรับทับทิม
• npmสำหรับ NodeJS
• bowerสำหรับ Javascript & CSS ส่วนหน้า
• นักเก็ตสำหรับ C #
• นักแต่งเพลงสำหรับ PHP

มีภาษาอื่นที่ใช้ระบบดังกล่าวหรือไม่? แล้ว C และ C ++ ล่ะ? (นั่นเป็นคำถามหลัก!) ทำไมไม่มีระบบดังกล่าวสำหรับพวกเขา? และไม่ได้มีการสร้างแพคเกจสำหรับyum, apt-getหรือระบบการจัดการแพคเกจอื่น ๆ ทั่วไปดีขึ้นหรือไม่

ที่จริงบางคน (ที่มีชื่อเสียงเพิ่มที่เห็นได้ชัด) กำลังทำงานอย่างหนักเพื่อสร้างและสร้างระบบดังกล่าวเรียกว่าRyppl มันยากที่จะสร้างระบบดังกล่าวสำหรับ C ++ เนื่องจากไม่มีผู้เล่นเดี่ยวที่สามารถกำหนดได้ - อัปเดต: น่าเสียดายที่มันถูกละทิ้ง

ในคำถามที่สองผู้จัดการแพคเกจปกติ (นอกเหนือจากการไม่ข้ามแพลตฟอร์ม) ไม่ตอบสนองความต้องการเฉพาะของนักพัฒนา

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

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

ฉันสามารถจินตนาการได้ว่าระบบที่ใช้สคริปต์สร้างและกำหนดค่า (ตามปกติบน Linux, cygwin และ Unix รสชาติอื่น ๆ ) สามารถใช้งานได้ แต่ทำไมผู้ใช้ Visual Studio จึงควรปรับใช้ เช่นเดียวกับที่ถูกต้องหากระบบเริ่มต้นแพคเกจขึ้นอยู่กับ Microsoft Compilers (และไลบรารี)

ความจริงที่ว่า C ++ เป็นภาษาที่พัฒนาอย่างรวดเร็วและมาตรฐานมักใช้เวลาพอสมควรก่อนที่จะได้รับการสนับสนุนอย่างเต็มที่จากคอมไพเลอร์ทั้งหมดไม่ได้ช่วยบรรเทาปัญหา

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

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

สิ่งนี้ทำให้ง่ายต่อการสร้างแพ็คเกจที่เพิ่งดาวน์โหลดและคอมไพล์ แน่นอนว่าหากมีการนำ C หรือ C ++ มาใช้ในปี 2013 ชุมชนของพวกเขาสามารถทำตามเส้นทางวิวัฒนาการที่คล้ายกันได้ แต่พวกเขาไม่ได้และไม่มี toolchain ที่มีอยู่เดียวที่จะนำไปใช้กับตัวจัดการแพ็คเกจ สิ่งนี้ทำให้การใช้งานโปรแกรมดังกล่าวยุ่งยากเกินไปที่จะคุ้มค่ากับความยุ่งยาก (คุณควรให้ผู้ใช้เลือกระหว่าง libfoo-gcc และ libfoo-vs หรือไม่คุณปล่อยให้มันถึงห่อเพื่อแก้ไขหรือกระบวนการสร้างหรือไม่ถ้าเป็นเช่นนั้นแพคเกจแตกต่างจาก tarball ตรงขึ้นอย่างไร)

ดังนั้นจะสรุปคำตอบของฉันคำถามแรกที่ผมคิดว่ารูปแบบของการสร้างผู้จัดการแพคเกจให้บริการส่วนใหญ่จะขับรถการยอมรับ

โดยที่ในใจฉันคิดว่ามันค่อนข้างง่ายที่จะดูว่าทำไมไม่มีระบบเดียวเพิ่มขึ้นเพื่อตอบสนองความต้องการนี้ - เนื่องจากความต้องการไม่มีอยู่สำหรับโปรแกรมเมอร์ C และ C ++ สิ่งที่ก่อให้เกิดปัญหาสำหรับชุมชน C และ C ++ (หรือชุมชนโปรแกรมเมอร์ใด ๆ จริง ๆ ) เป็นสิ่งที่จำเป็นต้องบอกเป็นนัยในตอนแรก: เพื่อแจกจ่ายให้ทันสมัยและสนับสนุนโค้ดกลับ สิ่งนี้ได้รับการแก้ไขหลายครั้งโดยคนที่แตกต่างกันซึ่งมีระดับความสำเร็จที่แตกต่างกันและแน่นอนว่าระบบหนึ่งระบบได้รับส่วนแบ่งการตลาดที่สำคัญ: git (และระบบอื่น ๆ ก่อนหน้านี้)

โดยทั่วไปเมื่อปัญหาแตกต่างกันวิธีแก้ไขก็ดูแตกต่างเช่นกัน แต่ IMHO แตกต่างกันระหว่างการพิมพ์gem installและgit clonemoot

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

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

สิ่งที่คุณพูดถึงคือYumและApt-getหรือ Rigo เป็นเพียงส่วนต่อประสานผู้ใช้สำหรับระบบการจัดการแพ็คเกจด้านล่าง

อีกหนึ่งรายการภาษาการเขียนโปรแกรม:

• นักแต่งเพลงและลูกแพร์สำหรับ PHP

ฉันรู้ว่านี่ไม่ใช่โซลูชันข้ามแพลตฟอร์ม แต่ควรเพิ่มในการผสม

CoApp เพิ่งประกาศสนับสนุนการจัดการแพ็คเกจ C ++ โดยใช้ NuGet: http://blog.nuget.org/20130426/native-support.html

ปัจจุบันนี้ใช้งานได้เฉพาะกับคอมไพเลอร์ Visual Studio แต่มีคำขอจำนวนมากที่จะได้รับการทำงานบนแพลตฟอร์มอื่น ๆ