কেন সি এবং সি ++ এর জন্য কোনও প্যাকেজ ম্যানেজমেন্ট সিস্টেম নেই? [বন্ধ]


78

কিছু প্রোগ্রামিং ভাষা রয়েছে যার জন্য একটি প্যাকেজ পরিচালনা ব্যবস্থা রয়েছে:

এই জাতীয় সিস্টেম সহ অন্য কোন ভাষা আছে? সি এবং সি ++ সম্পর্কে কী? (এটিই মূল প্রশ্ন!) তাদের জন্য কেন এমন কোনও ব্যবস্থা নেই? আর এর জন্য প্যাকেজ তৈরি করা হয় না yum, apt-getঅন্যান্য সাধারণ প্যাকেজ ম্যানেজমেন্ট সিস্টেম ভালো বা?


3
অবজেক্টিভ-সিতে কোকোপডস রয়েছে (রুবি রত্ন এবং বান্ডিলারের সাথে খুব মিল)। এত অদ্ভুত যে সি ++ এর মতো কিছু নেই। সম্ভবত কারণ সি ++ কম সমজাতীয়। অ্যাপল শীর্ষে প্যাকেজগুলি তৈরি করতে আরও মানক সামগ্রী সরবরাহ করে। সি ++ তে কেউ স্ট্রিং ক্লাসটি কী ব্যবহার করবে সে বিষয়ে খুব কমই একমত হতে পারে।
এরিক এনহিম

আমি কেবল এটিই উল্লেখ করতে চাই যে অন্যান্য ভাষার প্যাকেজ পরিচালকরা নিখুঁত নয়। উদাহরণস্বরূপ, রুবি রত্নগুলিতে প্রায়শই এমন একটি মণির মুখোমুখি হতে পারে যা নির্দিষ্ট ওএসের জন্য কাজ করে না (সম্ভবত উইন্ডোজের চেয়ে বেশি) এবং ডকুমেন্টেশন আপনাকে বলে না যে এটি ওএসের জন্য কাজ করে না।
ট্র্যাভিস পেসেটো

উত্তর:


28

আসলে কিছু লোক (লক্ষণীয় বস্ট খ্যাতির) রিপ্পল নামে একটি সিস্টেম তৈরি এবং প্রতিষ্ঠার জন্য কঠোর পরিশ্রম করছে । সি ++ এর জন্য এমন একটি সিস্টেম প্রতিষ্ঠা করা শক্ত, কারণ এর কোনও একক প্লেয়ার নেই যা এটি নির্দেশ করতে পারে। - আপডেট: দুর্ভাগ্যক্রমে এটি পরিত্যাজ্য।

আপনার দ্বিতীয় প্রশ্নে, একটি সাধারণ প্যাকেজ পরিচালক (ক্রস প্ল্যাটফর্ম না হওয়া ছাড়াও) বিকাশকারীদের নির্দিষ্ট প্রয়োজনগুলি পরিচালনা করে না।


2
বাহ, আমি অবাক হয়েছি কীভাবে তারা 20 বছরের লড়াই করতে চলেছে "আমাদের কোনও প্যাকেজ ম্যানেজারের দরকার নেই!"
TheLQ

8
ঠিক আছে, তারা বুস্ট খ্যাতির হয়ে উঠছে, আমি তাদের সন্দেহের সুবিধা দেব এবং একটি তাকাও করব। বুস্ট, সর্বোপরি, বেশ আশ্চর্যজনক :)
ওন্নো

2
@ দ্য এলকিউ - আমি মনে করি না যে এর আগে লড়াইয়ের পক্ষে আর কিছু করার আগে আর কেউ কার্যক্ষম সমাধান উপস্থাপন করেনি। 'আমাদের দুর্গন্ধযুক্ত প্যাকেজ ম্যানেজারের দরকার নেই' এমন নেই 'সেখানে কেউ আমাকে দরকারী বলে মনে হয় নি'। প্রাক্তন কাছাকাছি পাওয়া কঠিন হতে পারে, তবে আধুনিকটি সহজ: কেবল এমন কিছু উপস্থাপন করুন যা ডেভসকে তাদের কাজটি করতে সহায়তা করে।
মাইকেল কোহেন

1
এই উত্তরটি আপডেট করা উচিত: 1) রায়পাল একটি মৃত প্রকল্প, এমনকি এটির ওয়েবসাইটটি মারা গেছে। ২) সিপিএমের মতো অন্যান্য প্রকল্পগুলি (বাণিজ্যিক বা না) সম্প্রতি উদয় হয়েছে তাই সি ++ এর জন্য প্যাকেজ ম্যানেজার পাওয়ার জন্য অনেক কাজ চলছে। 3) আমি বিশ্বাস করি যে ভাষাতে মডিউল না আসা পর্যন্ত কোনও বিজয়ী থাকবে না এবং কোনও একটি সরঞ্জাম পুরোপুরি এটি কাজে লাগাতে পরিচালিত করে।
ক্লাইম

2
@ ক্লেইম পুনরায়: {মডিউলগুলি ভাষায় না হওয়া পর্যন্ত I যতদূর আমি বুঝতে পারি মডিউলগুলি জিনিসকে সহজতর করে তোলে না, এটি #includeকমান্ডের জন্য একটি বাক্য গঠন মাত্র sugar এটি সংস্করণকরণ / ডাউনলোডিং / ইনস্টল / সামঞ্জস্য / ক্রস-প্ল্যাটফর্মিক সি ++ সমস্যাগুলির মূল সমস্যার সমাধান করবে না।
ruslo

17

আমি মনে করি যে সি এবং আরও বেশি সি ++ এর সাথে সমস্যা হ'ল এগুলি আরও বিজাতীয় ভাষা: যদিও এই ভাষাগুলি প্রমিত হয় তবে বিভিন্ন বিকল্প বা সমর্থিত বৈশিষ্ট্যগুলির বিভিন্ন সেট সহ বিভিন্ন সংকলক রয়েছে exist উদাহরণস্বরূপ, আমি মনে করি জিসি / লিনাক্সে নিখুঁতভাবে কাজ করে এমন একটি উদাহরণ সহ স্ট্যাক ওভারফ্লোতে সি ++ সম্পর্কে একটি প্রশ্ন পোস্ট করেছি এবং কেউ সঙ্গে সঙ্গে একটি উত্তর পোস্ট করেছে যে আমার কোডটি মানহীন non

প্রশ্নে উল্লিখিতগুলির মতো প্যাকেজ সিস্টেম থাকার অর্থ একটি সাধারণ ভাষা এবং লাইব্রেরি রয়েছে যা সমস্ত সাধারণ অপারেটিং সিস্টেমে সমস্ত বড় কম্পাইলার দ্বারা সমানভাবে সমর্থিত হয়। উদাহরণস্বরূপ, আপনি একটি সি ++ প্যাকেজ ডাউনলোড করতে এবং এটি আবিষ্কার করতে চান না যে এটি আপনার সংকলক এক্স এর সংস্করণে সংকলন করবে না কারণ এটি অন্য অপারেটিং সিস্টেমের কম্পাইলার ওয়াইতে তৈরি হয়েছিল।

আমি কল্পনা করতে পারি যে স্ক্রিপ্টগুলি মেক এবং কনফিগার করার উপর ভিত্তি করে একটি সিস্টেম (সাধারণত লিনাক্স, সাইগউইন এবং অন্যান্য ইউনিক্স স্বাদে পাওয়া যায়) কাজ করতে পারে। তবে ভিজ্যুয়াল স্টুডিও ব্যবহারকারীরা কেন এটি গ্রহণ করবেন? যদি কেউ মাইক্রোসফ্ট কম্পাইলার (এবং গ্রন্থাগারসমূহ) এর ভিত্তিতে প্যাকেজ সিস্টেম শুরু করে তবে এটি একই বৈধ।

সি ++ একটি দ্রুত বিকাশমান ভাষা এবং এর মানগুলি সমস্ত সংকলক দ্বারা সম্পূর্ণরূপে সমর্থিত হওয়ার আগে কিছুটা সময় নেয় যা সমস্যা হ্রাস করে না।


ঠিক আছে, আপনি পোর্টেবল সি ++ লিখতে পারেন, বা আপনি একটি নির্দিষ্ট সরঞ্জামচেনে লিখতে পারেন। আপনার পছন্দ এবং কোনওটির সাথে কোনওরকম ভুল নেই, যদিও পূর্ববর্তীটির কোনও সুবিধা নেই যখন প্রাক্তন না করা কিছুটা আপোস্টিমাল।
ডিসিপ্লিকেটর

2
পোর্টেবল সি এবং সি ++ রয়েছে। কোনও ইনস্টলারের মাধ্যমে যদি কোনও লাইব্রেরি এককভাবে ইনস্টল করা না যায় তবে এটি পুনরায় তৈরি করা উচিত। এটি সম্পাদন করা পুরোপুরি সম্ভব। এমনকি নোডজেএসেও উইন্ডোজে অনেকগুলি মডিউল তৈরি করতে ব্যর্থ হয় তবে এটি এখনও বিদ্যমান থাকতে পারে, তাই মাঝে মাঝে বিল্ড ইস্যু কোনও সমস্যা নয় এবং কেন্দ্রীভূত প্যাকেজ ম্যানেজারটি ব্যবহারকারীদের প্রতিক্রিয়া প্রবাহিত করে এবং বিষয়গুলি মোকাবেলা করার জন্য আরও উত্সাহী করে তোলে।
দিমিত্রি

4

আমি মনে করি আপনার উত্তরগুলির জন্য আমাদের যে প্রশ্নগুলি জিজ্ঞাসা করতে হবে সেগুলি হ'ল "অন্যান্য ভাষা / বাস্তুতন্ত্রের নিজস্ব কেন্দ্রীভূত প্যাকেজ সংগ্রহস্থল থাকা থেকে কী লাভ হয়?" এবং "এটি কি সি / সি ++ এর জন্য প্রযোজ্য?"

আমি অনুভব করি যে প্রথম প্রশ্নের উত্তর একটি নতুন ভাষার প্রাথমিক প্রচারের সাথে কিছু আছে: প্রথমদিকে গ্রহণকারীরা বাস্তুতন্ত্রের প্রবেশের পক্ষে, দরকারী, পরীক্ষিত কোড অর্জন করতে এবং তাদের নিজস্ব ফিরিয়ে দেওয়ার জন্য এটি যতটা সম্ভব সহজ করে তুলতে চান। সুস্পষ্ট কারণে, "ব্যবহারের গ্রাফ" এর সর্বদা একক মূল থাকে - ভাষার স্রষ্টা (গুলি)। এখানে সাধারণত একটি রেফারেন্স বাস্তবায়ন হয় (কমপক্ষে প্রাথমিকভাবে) এবং সুতরাং যে কোনও কোড আপনি ভাগ করতে চাইতে পারেন তার সাথে এটি মেনে চলতে হবে।

এটি কেবল ডাউনলোড এবং সংকলনকারী প্যাকেজগুলি তৈরি করা সহজ করে। অবশ্যই, যদি 2013 সালে সি বা সি ++ চালু করা হত, তবে তাদের সম্প্রদায়গুলিও একই ধরণের বিবর্তনীয় পথ অনুসরণ করতে পারত, তবে তাদের কোনও প্যাকেজ ম্যানেজার প্রয়োগ করার জন্য কোনও একক প্রচলিত সরঞ্জামচয়ন নেই। এই জাতীয় প্রোগ্রাম বাস্তবায়ন খুব ঝামেলার উপযুক্ত হতে তোলে। (আপনি কি ব্যবহারকারীদের libfoo-gcc এবং libfoo-vs এর মধ্যে বেছে নিতে পারেন? সমাধানের জন্য আপনি কি এটি প্যাকেজরের উপরে ছেড়ে দিচ্ছেন? বা বিল্ড প্রক্রিয়া? যদি তা হয় তবে কীভাবে প্যাকেজ স্ট্রেট-আপ টারবালের চেয়ে আলাদা?)

সুতরাং প্রথম প্রশ্নের উত্তরটি সংক্ষেপে আমি মনে করি প্যাকেজ পরিচালকদের তৈরি করার প্যাটার্নটি বেশিরভাগ গ্রহণের জন্য চালিত করে ।

এই বিষয়টি মাথায় রেখে, আমি মনে করি কেন এটি প্রয়োজনীয়তা পূরণের জন্য কোনও একক সিস্টেমের উত্থান হয়নি - এটি সি এবং সি ++ প্রোগ্রামারদের জন্য প্রয়োজনীয়তার অস্তিত্ব নয় কেন তা মোটামুটি সহজ। সি এবং সি ++ সম্প্রদায়ের (বা কোনও প্রোগ্রামার সম্প্রদায়, সত্যই) কী সমস্যা তৈরি করে তা হ'ল মূলত অন্তর্নিহিত প্রয়োজন: বিতরণ করা, আপ টু ডেট রাখা এবং ব্যাক কোড অবদান। এটি বিভিন্ন সময়ে সাফল্যের বিভিন্ন ডিগ্রী সহ বিভিন্ন ব্যক্তি দ্বারা সমাধান করা হয়েছে, এবং প্রকৃতপক্ষে একটি সিস্টেম উল্লেখযোগ্য বাজার অংশ অর্জন করছে: গিট (এবং তার আগে কিছু অন্যান্য সিস্টেম)।

মূলত সেসব সমস্যাগুলোতে ভিন্ন, সমাধান খুব বিভিন্ন চেহারা, কিন্তু এই প্রোগ্রামটিতে টাইপিং মধ্যে পার্থক্য gem installএবং git cloneতর্ক করা হয়।


2
"অন্যান্য কেন্দ্রীভূত প্যাকেজ সংগ্রহস্থল রাখার মাধ্যমে অন্যান্য ভাষা / বাস্তুতন্ত্রগুলি কী লাভ করে?"। আপনার সফ্টওয়্যারটি সঠিকভাবে কাজ করার জন্য প্যাকেজগুলি ডাউনলোড করা এবং তাদের বিশ্বাস করা শুরু করতে আপনার খুব অভিজ্ঞ বিকাশকারী হতে হবে। প্যাকেজ পরিচালক থাকাকালীন লোকেরা প্রসঙ্গ সংবেদনশীল বিল্ড নির্দেশাবলী / এর সাথে ডিল করার পরিবর্তে প্যাকেজগুলি ব্যবহার শুরু করতে দেয়। আমি নিজেও মিনজিডব্লিউতে কীভাবে কাজ করতে উত্সাহ পেতে পারি তা বুঝতে পারি না, সুতরাং আমি কেবল এটি ব্যবহার না করে এর বেশিরভাগ কার্যকারিতা নিজেই লিখে ফেলছি। এটা বোকামি না।
দিমিত্রি

1
বিভিন্ন ইনস্টল / বিল্ড স্ক্রিপ্ট এবং পতাকা নিয়ে লড়াই না করা দুর্দান্ত জয় হবে।
themihai

3

এই প্রশ্নে কিছুটা বিভ্রান্তি আছে। উল্লিখিত সফ্টওয়্যার নির্দিষ্ট প্রোগ্রামিং ভাষার জন্য এক্সটেনশন পরিচালনা করে। তারা লাইব্রেরি এবং উত্স কোড সরবরাহ করে যা পরবর্তীতে আপনার পছন্দমতো প্রোগ্রামিং ভাষার সাথে আপনার প্রোগ্রামে ব্যবহৃত হতে পারে।

সাধারণ সিস্টেম স্তরের প্যাকেজ পরিচালনাকারীরা সাধারণত বাইনারি প্যাকেজ সরবরাহ করে যা অ্যাপ্লিকেশন নির্বিশেষে ব্যবহার করা যেতে পারে। তারা সিস্টেম এবং ব্যবহারকারীর প্রতি আরও বেশি আগ্রহী। অবশ্যই, অ্যাপটিটিউড, আরপিএম, এন্ট্রপি যেমন সিস্টেম স্তরের প্যাকেজ পরিচালন সিস্টেমগুলি যে কোনও প্যাকেজ সরবরাহ করতে পারে , এটি বাইনারি বা উত্স কোড হ'ল। এ কারণেই আপনি বেশিরভাগ এক্সটেনশানগুলি আপনার সাথে ইনস্টল করবেন ... উদাহরণস্বরূপ রত্ন

এর চেয়ে কম, আপনি ইয়াম এবং অ্যাপটি - গেট বা রিগো হিসাবে উল্লেখ করেছেন কেবল সেগুলির নীচের প্যাকেজ পরিচালনা সিস্টেমগুলির জন্য কেবল ব্যবহারকারী ইন্টারফেস।

প্রোগ্রামিং ভাষার তালিকাগুলির জন্য আরও একটি:

  • পিএইচপি জন্য সুরকার এবং নাশক

হাঁ অবশ্যই. শেষ তিনটি প্রশ্ন লেখার সময় আমি কী ভাবছিলাম?
এম0 নাহক

সমস্যাটি হ'ল এই প্যাকেজগুলি স্থানীয়ভাবে না হয়ে বিশ্বব্যাপী পান এবং আপনার প্রকল্পের নির্ভরতাগুলি একক ফোল্ডারে বান্ডিল করা খুব কঠিন। এর অর্থ হ'ল কোনও প্রকল্প আপনার সিস্টেমে কাজ করতে পারে তবে আপনি এটি অন্য সিস্টেমে রাখার সাথে সাথে আপনাকে কীসের উপর নির্ভরশীল তা মনে রাখতে হবে এবং সেগুলি সবগুলি পেতে এবং আপনার প্রকল্পটি তাদের প্রত্যাশা করে ঠিক জায়গায় রেখে দেয়। এই প্রক্রিয়াটি নরক। এর উদাহরণ জিটিকে, বিশ্বব্যাপী ইনস্টল করা সহজ, স্থানীয়ভাবে ইনস্টল করা শক্ত।
দিমিত্রি

0

আমি বুঝতে পারি এটি কোনও ক্রস প্ল্যাটফর্ম সমাধান নয়, তবে এটি মিশ্রণে যুক্ত করা উচিত।

কোপ্প সম্প্রতি নিউগেট ব্যবহার করে সি ++ প্যাকেজ পরিচালনার জন্য সমর্থন ঘোষণা করেছে: http://blog.nuget.org/20130426/native-support.html

এটি বর্তমানে ভিজ্যুয়াল স্টুডিও সংকলকটির সাথে কাজ করে তবে অন্যান্য প্ল্যাটফর্মগুলিতে এটি কাজ করার জন্য অনেক অনুরোধ রইল।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.