C और C ++ के लिए कोई पैकेज मैनेजमेंट सिस्टम क्यों नहीं हैं? [बन्द है]

Question

कुछ प्रोग्रामिंग भाषाएं हैं जिनके लिए एक पैकेज प्रबंधन प्रणाली मौजूद है:

• TeX के लिए CTAN
• पर्ल के लिए सीपीएएन
• अजगर के लिए पिप और अंडे
• जावा के लिए मावेन
• कबाल हास्केल के लिए
• रूबी के लिए रत्न
• NPM NodeJS के लिए
• जावास्क्रिप्ट और सीएसएस दृश्यपटल के लिए bower
• सी # के लिए नगेट
• PHP के लिए संगीतकार

क्या ऐसी प्रणालियों के साथ कोई अन्य भाषा है? C और C ++ के बारे में क्या? (यह मुख्य प्रश्न है!) उनके लिए ऐसी कोई व्यवस्था क्यों नहीं है? और के लिए पैकेज नहीं बना रहा है yum, apt-getअन्य सामान्य पैकेज प्रबंधन प्रणाली बेहतर या?

Comments

ऑब्जेक्टिव-सी में कोकोपोड्स हैं (रूबी रत्नों और बंडल के समान)। इतना अजीब कि C ++ में कुछ समान नहीं है। शायद इसलिए कि सी ++ कम समरूप है। Apple शीर्ष पर पैकेज बनाने के लिए अधिक मानक सामान प्रदान करता है। C ++ में शायद ही कोई इस बात पर सहमत हो सके कि किस स्ट्रिंग क्लास का उपयोग करना है।

— एरिक इंगहेम

मैं केवल यह बताना चाहूंगा कि अन्य भाषाओं के पैकेज प्रबंधक परिपूर्ण नहीं हैं। उदाहरण के लिए, रूबी जेम्स में अक्सर एक मणि का सामना हो सकता है जो एक विशिष्ट ओएस (संभावना से अधिक विंडोज) के लिए काम नहीं करता है और प्रलेखन आपको यह नहीं बताता है कि यह उस ओएस के लिए काम नहीं करता है।

— ट्रैविस पेसेटो

stackoverflow.com/questions/7266097/…

— Ciro Santilli 改造 .com/ est est est at

Answer 1

वास्तव में कुछ लोग (ध्यान देने योग्य बढ़ावा देने वाली प्रसिद्धि) ऐसी प्रणाली बनाने और स्थापित करने के लिए कड़ी मेहनत कर रहे हैं, जिन्हें Ryppl कहा जाता है । सी ++ के लिए इस तरह की प्रणाली स्थापित करना कठिन है, क्योंकि इसके पास एक भी खिलाड़ी नहीं है जो इसे निर्देशित कर सके। - अद्यतन: दुर्भाग्य से यह छोड़ दिया है।

आपके दूसरे प्रश्न पर, एक सामान्य पैकेज मैनेजर (क्रॉस प्लेटफॉर्म के अलावा नहीं) डेवलपर्स की विशिष्ट आवश्यकताओं को नहीं संभालता है।

Comments

वाह, मुझे आश्चर्य है कि वे "हम पैकेज मैनेजर की आवश्यकता नहीं है" के 20 साल कैसे लड़ने जा रहे हैं!

— एलएलक्यू

खैर, वे बूस्ट की ख्याति के हैं, मैं उन्हें संदेह का लाभ दे दूँगा और एक नज़र रखना होगा। बूस्ट, आखिरकार, काफी आश्चर्यजनक है :)

— ओनो

@ TheLQ - मुझे नहीं लगता कि इसके अलावा लड़ने के लिए कुछ भी नहीं है कि किसी ने पहले एक व्यावहारिक समाधान प्रस्तुत नहीं किया है। वहाँ कोई 'हम stink'n पैकेज प्रबंधक की जरूरत नहीं है' वहाँ है 'कोई मुझे कुछ भी है कि उपयोगी लगता है दिखाया है'। पूर्व को प्राप्त करना मुश्किल हो सकता है, लेकिन उत्तरार्द्ध सरल है: बस कुछ ऐसा पेश करें जो वास्तव में देवों को अपना काम करने में मदद करें।

— माइकल कोहनी

इस उत्तर को अद्यतन किया जाना चाहिए: 1) रयपल एक मृत परियोजना है, यहां तक ​​कि यह वेबसाइट मर चुकी है। 2) अन्य प्रोजेक्ट (वाणिज्यिक या नहीं) जैसे cpm में हाल ही में स्पॉन है, इसलिए C ++ के लिए पैकेज मैनेजर प्राप्त करने के लिए बहुत सारे काम किए जा रहे हैं। 3) मेरा मानना ​​है कि जब तक मॉड्यूल भाषा में नहीं होंगे तब तक कोई विजेता नहीं होगा और उनमें से एक उपकरण का उपयोग पूरी तरह से करने के लिए किया जाता है।

— 21

@ पुनः प्राप्त करें: {जब तक मॉड्यूल भाषा में हैं} जहां तक ​​मैं समझता हूं कि मॉड्यूल चीजों को आसान नहीं बनाते हैं, यह #includeकमांड के लिए सिर्फ एक वाक्यविन्यास चीनी है । यह वर्जनिंग / डाउनलोडिंग / इनस्टॉलिंग / कम्पैटिबिलिटी / क्रॉस-प्लेटफ़ॉर्म C ++ मुद्दों की मुख्य समस्या को हल नहीं करेगा।

— रासलो

Answer 2

मुझे लगता है कि C के साथ और यहां तक ​​कि C ++ के साथ एक समस्या यह है कि वे अधिक विषम भाषाएं हैं: भले ही इन भाषाओं को मानकीकृत किया गया हो लेकिन अलग-अलग विकल्प या समर्थित सुविधाओं के विभिन्न सेटों के साथ अलग-अलग संकलक मौजूद हैं। उदाहरण के लिए, मुझे एक उदाहरण के साथ स्टैक ओवरफ्लो पर C ++ के बारे में एक प्रश्न पोस्ट करना याद है जो जीसीसी / लिनक्स पर पूरी तरह से काम कर रहा था और किसी ने तुरंत एक जवाब पोस्ट करते हुए कहा कि मेरा कोड गैर-मानक था।

प्रश्न में उल्लिखित लोगों की तरह एक पैकेज प्रणाली होने का मतलब यह होगा कि सभी सामान्य ऑपरेटिंग सिस्टम पर सभी प्रमुख कंपाइलरों द्वारा समान रूप से समर्थित एक सामान्य भाषा और पुस्तकालय हैं। उदाहरण के लिए, आप C ++ पैकेज डाउनलोड नहीं करना चाहते हैं और यह जानते हैं कि यह आपके संकलक X के संस्करण पर संकलित नहीं करेगा क्योंकि यह एक अन्य ऑपरेटिंग सिस्टम पर संकलक Y पर विकसित किया गया था।

मैं कल्पना कर सकता हूं कि स्क्रिप्ट बनाने और कॉन्फ़िगर करने पर आधारित प्रणाली (जैसा कि आमतौर पर लिनक्स, साइबरविन और अन्य यूनिक्स फ्लेवर्स पर पाया जाता है) काम कर सकती है। लेकिन विजुअल स्टूडियो उपयोगकर्ताओं को इसे क्यों अपनाना चाहिए? यदि कोई Microsoft कंपाइलर (और लाइब्रेरी) पर आधारित एक पैकेज सिस्टम शुरू करता है तो यह मान्य है।

यह तथ्य कि C ++ एक तेजी से विकसित होने वाली भाषा है और इसके मानक हमेशा सभी कंपाइलरों द्वारा पूरी तरह से समर्थित होने से पहले कुछ समय लेते हैं, समस्या को कम नहीं करते हैं।

Comments

ठीक है, आप पोर्टेबल सी ++ लिख सकते हैं, या आप एक विशिष्ट टूलचैन को लिख सकते हैं। आपकी पसंद, और कुछ भी गलत नहीं है, हालांकि पूर्व नहीं कर रहा है जब बाद का कोई फायदा नहीं है, कुछ हद तक सबॉप्टीमल है।

— Deduplicator

पोर्टेबल C और C ++ है। यदि एक इंस्टॉलर द्वारा लाइब्रेरी को एक स्टैंडअलोन तरीके से आसानी से स्थापित नहीं किया जा सकता है, तो इसे रीमेड किया जाना चाहिए। इसे पूरा करना पूरी तरह संभव है। NodeJS में भी कई मॉड्यूल विंडोज पर निर्माण करने में विफल होते हैं, लेकिन यह अभी भी मौजूद है, इसलिए कभी-कभी बिल्ड समस्याएँ एक समस्या नहीं हैं, और एक केंद्रीकृत पैकेज प्रबंधक उपयोगकर्ताओं से प्रतिक्रिया सुव्यवस्थित करता है और मुद्दों से निपटने के लिए इसे और अधिक प्रोत्साहन देता है।

— दिमित्री

Answer 3

मुझे लगता है कि आपके जवाब देने के लिए हमें जो प्रश्न पूछने की आवश्यकता है, वे हैं "अन्य भाषाएं / पारिस्थितिक तंत्र अपने स्वयं के केंद्रीकृत पैकेज भंडार से क्या प्राप्त करते हैं?" और "क्या यह C / C ++ पर लागू होता है?"

मुझे लगता है कि पहले प्रश्न के उत्तर का नई भाषा के शुरुआती प्रचार से कुछ लेना-देना है: शुरुआती अपनाने वाले नए लोगों के लिए पारिस्थितिकी तंत्र में प्रवेश करना, उपयोगी, परीक्षण किए गए कोड प्राप्त करना और अपना स्वयं का योगदान देना आसान बनाना चाहते हैं। स्पष्ट कारणों के लिए, "उपयोग ग्राफ" में हमेशा एक ही मूल होता है - भाषा का निर्माता (रों)। आमतौर पर एक संदर्भ कार्यान्वयन होता है (कम से कम शुरू में) और इसलिए कोई भी कोड जिसे आप साझा करना चाहते हैं, उसके अनुरूप होना चाहिए।

यह उन पैकेजों को बनाना आसान बनाता है जो बस डाउनलोड और संकलन करते हैं। निश्चित रूप से, 2013 में C या C ++ को पेश किया गया था, उनके समुदाय एक समान विकासवादी पथ का अनुसरण कर सकते थे, लेकिन उनके पास पैकेज प्रबंधक को लागू करने के लिए कोई भी प्रचलित टूलचिन नहीं था। यह इस तरह के कार्यक्रम के कार्यान्वयन को परेशानी के लायक बनाता है। (क्या आपको उपयोगकर्ताओं को libfoo-gcc और libfoo-vs के बीच चयन करना चाहिए? क्या आप इसे हल करने के लिए ग्रामीण तक छोड़ देते हैं? या निर्माण प्रक्रिया? यदि हां, तो पैकेज सीधे टारबॉल से अलग कैसे है?)

इसलिए पहले सवाल के लिए मेरे जवाब को समझने के लिए, मुझे लगता है कि पैकेज मैनेजर बनाने का पैटर्न ज्यादातर गोद लेने के लिए काम करता है ।

इसे ध्यान में रखते हुए, मुझे लगता है कि यह देखना काफी आसान है कि कोई एकल प्रणाली इस आवश्यकता को पूरा करने के लिए क्यों नहीं बढ़ी है - क्योंकि सी और सी ++ प्रोग्रामर के लिए आवश्यकता मौजूद नहीं है। सी और सी ++ समुदाय (या किसी भी प्रोग्रामर समुदाय, वास्तव में) के लिए एक समस्या का गठन क्या है जो मूल रूप से निहित है: वितरित करने, अद्यतित रहने और वापस कोड योगदान करने के लिए। यह कई बार अलग-अलग लोगों द्वारा सफलता की बदलती डिग्री के साथ हल किया गया है, और वास्तव में एक प्रणाली महत्वपूर्ण बाजार हिस्सेदारी हासिल कर रही है: गिट (और इससे पहले कुछ अन्य सिस्टम)।

मूल रूप से जब समस्याएं अलग होती हैं, तो समाधान भी अलग-अलग दिखते हैं, लेकिन IMHO टाइपिंग gem installऔर git cloneमूट के बीच का अंतर है।

Comments

"अन्य भाषाओं / पारिस्थितिक तंत्रों को अपने स्वयं के केंद्रीकृत पैकेज भंडार होने से क्या हासिल होता है?"। आपको संकुल को डाउनलोड करने और अपने सॉफ़्टवेयर के साथ ठीक से काम करने के लिए उन पर भरोसा करने के लिए एक बहुत ही अनुभवी डेवलपर होने की आवश्यकता है। पैकेज मैनेजर होने से लोग संदर्भ के प्रति संवेदनशील निर्माण निर्देशों / इत्यादि से निपटने के बजाय सिर्फ पैकेज का उपयोग शुरू कर सकते हैं। मैं खुद यह पता नहीं लगा सकता कि मिंज डब्ल्यू पर काम करने के लिए बढ़ावा कैसे मिलता है, इसलिए मैं अंत में इसका उपयोग करने के बजाय इसे खुद से अधिक कार्यक्षमता लिख ​​रहा हूं। यह मूर्खतापूर्ण नहीं है।

— दिमित्री

विभिन्न स्थापित / निर्माण स्क्रिप्ट और झंडे के साथ लड़ने के लिए नहीं एक महान जीत होगी।

— थीमीहाई

Answer 4

इस सवाल में थोड़ा भ्रम है। उपर्युक्त सॉफ्टवेयर विशिष्ट प्रोग्रामिंग भाषाओं के लिए एक्सटेंशन का प्रबंधन करता है। वे पुस्तकालयों और स्रोत कोड प्रदान करते हैं जो बाद में आपकी पसंद की प्रोग्रामिंग भाषा के साथ आपके कार्यक्रम में उपयोग किया जा सकता है।

जबकि सामान्य प्रणाली स्तर पैकेज मैनर्स आमतौर पर बाइनरी पैकेज प्रदान करते हैं जिनका उपयोग एप्लिकेशन की परवाह किए बिना किया जा सकता है। वे सिस्टम और उपयोगकर्ता पर अधिक उन्मुख हैं। बेशक, सिस्टम स्तर पैकेज प्रबंधन प्रणाली जैसे एप्टीट्यूड, आरपीएम, एन्ट्रॉपी किसी भी पैकेज को प्रदान कर सकती है , यह द्विआधारी या स्रोत कोड है। यही कारण है कि आप उनमें से अधिकांश एक्सटेंशन के साथ स्थापित करेंगे ... उदाहरण के लिए मणि ।

थान, जिसे आपने यम और Apt-get या Rigo के रूप में उल्लेख किया है, उनके नीचे पैकेज प्रबंधन प्रणालियों के लिए केवल उपयोगकर्ता इंटरफेस हैं।

सूची ओ प्रोग्रामिंग भाषाओं के लिए एक और:

• PHP के लिए संगीतकार और नाशपाती

Comments

हां निश्चित रूप से। पिछले तीन प्रश्नों को लिखते समय मैं क्या सोच रहा था?

— m0nhawk

मुद्दा यह है कि ये पैकेज स्थानीय स्तर पर होने के बजाय वैश्विक रूप से मिलते हैं, और आपकी परियोजना की निर्भरता को एक एकल फ़ोल्डर में बांधना बहुत मुश्किल है। इसका मतलब है कि एक परियोजना आपके सिस्टम पर काम कर सकती है, लेकिन जैसे ही आप इसे किसी अन्य सिस्टम पर डालते हैं, आपको यह याद रखने की आवश्यकता है कि यह किस पर निर्भर करता है और उन सभी को प्राप्त करें और उन्हें सटीक स्थानों पर रखें जहां आपकी परियोजना उनसे उम्मीद करती है। यह प्रक्रिया नरक है। इसका एक उदाहरण जीटीके है, जो विश्व स्तर पर स्थापित करना आसान है, स्थानीय स्तर पर स्थापित करना कठिन है।

— दिमित्री

Answer 5

मुझे लगता है कि यह एक क्रॉस-प्लेटफॉर्म समाधान नहीं है, लेकिन इसे मिश्रण में जोड़ा जाना चाहिए।

CoApp ने हाल ही में NuGet का उपयोग करते हुए C ++ पैकेज प्रबंधन के लिए समर्थन की घोषणा की: http://blog.nuget.org/20130426/native-.html

यह वर्तमान में केवल विजुअल स्टूडियो कंपाइलर के साथ काम करता है, लेकिन अन्य प्लेटफार्मों पर इस काम को पाने के लिए कई अनुरोध किए गए हैं।