মেকফিলগুলি কেন "ইনস্টল" লক্ষ্য রাখতে হবে?

Question

সি এবং সি ++ এর বিশ্ব থেকে আগত, বেশিরভাগ বিল্ড সিস্টেমের একটি installলক্ষ্য রয়েছে, উল্লেখযোগ্যভাবে মেকফাইলস (যেখানে এটি জিএনইউ উদাহরণস্বরূপ প্রস্তাবিত হয় ) বা সিএমকেক । এই লক্ষ্যটি অপারেটিং সিস্টেমে রানটাইম ফাইলগুলি (এক্সিকিউটেবল, গ্রন্থাগার, ...) অনুলিপি করে (উদাহরণস্বরূপ, C:\Program Files\উইন্ডোজে)।

এটি সত্যই হ্যাকিং অনুভব করে, যেহেতু প্রোগ্রামগুলি ইনস্টল করার জন্য বিল্ড সিস্টেমের দায়িত্ব আমার নেই (এটি আসলে অপারেটিং সিস্টেম / প্যাকেজ ম্যানেজারের দায়িত্ব)। এর অর্থ হ'ল বিল্ড সিস্টেম বা বিল্ড স্ক্রিপ্টটি অবশ্যই পরিবেশিত ভেরিয়েবল, রেজিস্ট্রি ভেরিয়েবল, সিমলিংক, অনুমতি ইত্যাদির সাথে ইনস্টলড প্রোগ্রামগুলির সংগঠনটি জানতে হবে must

সর্বোপরি, বিল্ড সিস্টেমগুলির একটি releaseলক্ষ্য থাকা উচিত যা একটি ইনস্টলযোগ্য প্রোগ্রাম আউটপুট দেয় (উদাহরণস্বরূপ .debবা .msi) এবং তারপরে অপারেটিং সিস্টেমটিকে দয়া করে সেই প্রোগ্রামটি ইনস্টল করতে বলে। এটি ব্যবহারকারীকে টাইপ না করেই আনইনস্টল করার অনুমতি দেয় make uninstall।

সুতরাং, আমার প্রশ্ন: বিল্ড সিস্টেম সাধারণত installলক্ষ্য রাখার পরামর্শ দেয় কেন ?

Comments

আপনার যুক্তি যে "মেক ইনস্টল" কোনও বিল্ড সিস্টেমের দায়িত্বে আসে না, তবে ইনস্টলযোগ্য প্যাকেজ তৈরির ক্ষেত্রে আরও অনেক বেশি জড়িত এবং প্ল্যাটফর্মের সুনির্দিষ্ট দায়িত্ব পালন করে।

— pmf

যাইহোক: কখনও কখনও আপনি একটি অ্যাপ্লিকেশন ইনস্টল করতে চান যা ওএস / প্যাকেজ ম্যানেজার দ্বারা পরিচালিত হয় না (কারণ এটির নির্ভরতাগুলি প্যাকেজ ম্যানেজার ইত্যাদির সাহায্যে দ্বন্দ্বগুলি অসম্ভবকে সমাধান করতে পারে)। make installসাধারণত /usr/local(বা এমনকি /opt) এর অধীন ইনস্টল করা হয় যা ডিরেক্টরিগুলি "কোর ওএস / প্যাকেজ পরিচালনা সিস্টেম" দ্বারা পরিচালিত হয় না। যদিও উইন্ডোজ কিছু অনুরূপ কনভেনশন আছে কিনা ধারণা নেই।

— বাকুরিউ

"এটাকে সত্যিই খুব খারাপ মনে হচ্ছে।" আচ্ছা, আপনি সি / সি +++ এর বিশ্ব থেকে কী আশা করেছিলেন? ;-)

— ম্যাসন হুইলার

দ্রষ্টব্য যে make installযখন আমরা ক্রস সংকলনের বিষয়ে কথা বলি তখন কোনও অর্থ হয় না

— হেগেন ভন ইটজেন

@HagenvonEitzen এটা দিয়ে কাজ করে DESTDIR।

— ন্যাক্স 'vi-vim-nvim'

Answer 1

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

Comments

আমি পছন্দ করি এমন সিস্টেমগুলির বিষয়ে কৌতূহলী make install। এগুলি ছাড়াও, আমি প্রোগ্রাম ম্যানেজারকে বুঝিয়েছিলাম যখন আমি বলেছিলাম যে মেকফিলগুলি ইনস্টলযোগ্য প্যাকেজ তৈরি করতে পারে। আমি মনে করি প্রায় সমস্ত ওএস ইনস্টলড প্রোগ্রাম পরিচালনা করার উপায় নিয়ে আসে? উদাহরণস্বরূপ, উইন্ডোজের কোনও প্যাকেজ ম্যানেজার নেই (স্টোর বাদে) তবে ইনস্টলড প্রোগ্রামগুলি পরিচালনা করার উপায় রয়েছে (উদাহরণস্বরূপ .msiপ্যাকেজগুলির মাধ্যমে )

— Synxis

@ সিংসিস বিএসডি, লিনাক্স, ইউনিক্স সমস্ত মেকফাইল ব্যবহার করুন। এটি ইনস্টলেশনের জন্য সেগুলি ব্যবহার করা পছন্দ করে কিনা, আমি জানি না, তবে আপনার প্রায়শই ব্যবহার করার ক্ষমতা থাকে make install।

— রব

ডেবিয়ানে কমপক্ষে এটি দুটি কারণে checkinstallবেশি ব্যবহার করা পছন্দ করা হয় make install: "আপনি সহজেই এক পদক্ষেপের সাহায্যে প্যাকেজটি সরাতে পারেন।" এবং "আপনি একাধিক মেশিনে ফলাফল প্যাকেজ ইনস্টল করতে পারেন।" - চেকইনস্টলটি একটি .deb তৈরি করে এবং এটি ইনস্টল করার সাথে সাথে এটি প্যাকেজ ম্যানেজারটি ব্যবহার করে ...

— অ্যারন হল

@ সিনেক্সিস - এখানে বেশ কয়েকটি লিনাক্স ডিস্ট্রিবিউশন রয়েছে (প্রায়শই সোর্স ডিস্ট্রোস বলা হয়) যেখানে প্যাকেজ ম্যানেজার একটি টার ফাইল ডাউনলোড করে প্রোগ্রাম ইনস্টল করে, এটি make install

— সংক্ষেপিত

@ অ্যারনহল আমি ভুল হলে আমাকে সংশোধন করুন, তবে আমার ধারণাটি পেয়েছিল যে একটি প্রার্থনা checkinstallআসলে প্যাকেজ তৈরির জন্য এর ক্রিয়াগুলি ব্যবহার করবে make installএবং তা নিরীক্ষণ করবে।

— cmaster - পুনর্বহাল মনিকা

Answer 2

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

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

আপনার সিস্টেমের বেশিরভাগ এক্সিকিউটেবলের জন্য স্ট্রিং (1) ব্যবহার করার চেষ্টা করুন । কোন ফাইল পাথ এটি পরিচিত তা আপনি খুঁজে পাবেন।

বিটিডাব্লু, অনেক জিএনইউ প্রোগ্রাম ব্যবহার করে autoconfআপনি make install DESTDIR=/tmp/destdir/রুট না হয়ে চলতে পারেন । তারপরে /tmp/destdir/ফাইলগুলি পূরণ করা হয় যা পরে প্যাকেজ করা উচিত।

এফডব্লিউআইডাব্লু, আমি বিশ্বাস করি যে আমার বিসমন (জিপিএলভি 3 + লাইসেন্সযুক্ত) প্রোগ্রামটি (আমার বিসমন-রথ-ডক.পিডিএফ রিপোর্টে বর্ণিত ) "ইনস্টল" করা যাবে না; আমি এটি প্রমাণ করতে সক্ষম হওয়ার বিষয়ে নিশ্চিত নই এবং আমি কীভাবে সেই প্রোগ্রামটি ইনস্টলযোগ্য করতে পারি তা আমি ভাবতে পারি না।

Comments

DESTDIR বা অন্যান্য উপসর্গগুলি প্রায়শই ভুলে যায়। গতিশীল লাইব্রেরিগুলির মতো বাহ্যিক সংস্থানগুলি জড়িত হওয়ার সাথে সাথে সফ্টওয়্যারটি কোথায় ইনস্টল করা হবে তা জেনেও এটি তৈরি করা সম্ভব নয় । অ-মানক অবস্থানগুলিতে ইনস্টল করার জন্য দুর্দান্ত, উদাহরণস্বরূপ বা এর মধ্যে । বিভিন্ন উপসর্গ এড়ানোর একমাত্র উপায় হ'ল পাত্রে ব্যবহার করা, তবে এটি অবশ্যই একটি লিনাক্স-নির্দিষ্ট সমাধান। /opt$HOME

— আমন

আমি একাধিক প্যাকেজ দেখেছি যে আপনি যদি DESTDIR = / tmp / destdir চেষ্টা করে থাকেন তবে সাধারণ স্থানে ইনস্টল করার পরে পরে কাজ করবে না কারণ DESTDIR পথ তৈরিতে ব্যবহৃত হয়েছিল।

— জোশুয়া

@amon: আমি নিশ্চিত নই যে আমি ধারকগুলি লিনাক্স-নির্দিষ্ট হিসাবে চিহ্নিত করব। লিনাক্স কনটেইনারাইজেশনের জন্য একটি সাধারণ লক্ষ্য প্ল্যাটফর্ম হতে পারে তবে বেশিরভাগ আধুনিক অপারেটিং সিস্টেমে কিছু ধারক প্রযুক্তির উপস্থিতি রয়েছে।

— কেভিন

@ জোশুয়া এটি করা উচিত নয়, ডিএসটিডিআর কেবল ইনস্টল পদক্ষেপের সময় প্রাসঙ্গিক হওয়া উচিত। আপনার করতে সক্ষম হবেন: ./configure --prefix="/opt/foo" && make && DESTDIR=/tmp/foo make install এবং /opt/fooকোনও সমস্যা ছাড়াই প্যাকেজটি স্থানান্তর করতে সক্ষম হবেন ।

— ন্যাক্স 'vi-vim-nvim'

Answer 3

মাথায় আসা বিভিন্ন কারণ আছে।

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

Comments

আমি প্রশ্নটি কিছুটা উচ্চারণ করেছিলাম, আমি যখন প্রোগ্রাম ম্যানেজারকে ইনস্টলযোগ্য প্যাকেজ তৈরি করতে চেয়েছিলাম তখন আমি প্রোগ্রাম ম্যানেজারকে বোঝাতে চাইছিলাম।

— সংশ্লেষণ

Answer 4

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

ধরা যাক আপনি ওপেন সোর্স প্রজেক্ট FOO ব্যবহার করছেন যা বর্তমানে 2.0.1 সংস্করণে রয়েছে এবং আপনি সংস্করণ 1.3.0 ব্যবহার করছেন। আপনি উপরে কিছু ব্যবহার করতে চান না কারণ 2.0.0 সংস্করণ আপনি বর্তমানে যা করছেন তার সাথে সামঞ্জস্যপূর্ণ নয়, তবে আপনার মরিয়া হওয়া দরকার ২.০.১ এ একক বাগ ফিক্স রয়েছে। make installবিকল্পটি থাকা অবস্থায় আপনি প্যাকেজ তৈরির বিষয়ে চিন্তা না করে আপনার পরিবর্তিত 1.3.0 সফ্টওয়্যারটি ইনস্টল করুন এবং এটি আপনার সিস্টেমে ইনস্টল করুন।

Answer 5

লিনাক্স বিতরণগুলি সাধারণত প্যাকেজ রক্ষণাবেক্ষণ থেকে প্রোগ্রাম রক্ষণাবেক্ষণ পৃথক করে। একটি বিল্ড সিস্টেম যা প্যাকেজ প্রজন্মকে সংহত করে প্রোগ্রাম রক্ষণাবেক্ষণকারীদেরকে প্যাকেজ রক্ষণাবেক্ষণ করতে বাধ্য করে।

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

বিল্ড সিস্টেম থেকে সরাসরি প্যাকেজগুলি তৈরি করতে আপনাকে এই সমস্ত অবকাঠামোকে একত্রিত করতে বা বাইপাস করতে হবে। এটি সংহত করা প্রশ্নবিদ্ধ সুবিধার জন্য অনেক কাজ হবে এবং এটিকে বাইপাস করা আরও খারাপ ব্যবহারকারীর অভিজ্ঞতা দেবে।

এটি মাল্টি-পার্টি সিস্টেমে সাধারণ যে "খাদ্য চেইনের শীর্ষ" সমস্যাগুলির মধ্যে একটি। আপনার যদি একাধিক জটিল সিস্টেম থাকে তবে অন্যান্য সিস্টেমের সমন্বয়ের জন্য কোন সিস্টেমটি দায়বদ্ধ তা সম্পর্কে একটি স্পষ্ট শ্রেণিবদ্ধতা থাকা দরকার।

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

প্যাকেজ ম্যানেজার এখানে বিল্ড সিস্টেম এবং সংগ্রহস্থলের মাঝখানে দাঁড়িয়ে আছে এবং উভয়ের সাথে ভালভাবে সংহত করার জন্য সেরা অবস্থানে রয়েছে।

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

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

Comments

কেন আপনি একটি ইনস্টল লক্ষ্য আছে সে সম্পর্কে কিছুই বলেননি, এবং আমার কাছে মনে হয়েছে আপনি যা লিখেছেন তার

— বেশিরভাগ অংশই

@ কুরিয়াসননি, বিল্ড সিস্টেম এবং প্যাকেজ ম্যানেজারের মধ্যে কিছু ইন্টারফেস হওয়া দরকার , এবং এটি সবচেয়ে সহজ হিসাবে ঘটে তাই এটি জিতেছে।

— সাইমন রিখটার

Answer 6

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

তিনি একটি স্বেচ্ছাসেবী নাম সহ একটি ইনস্টল স্ক্রিপ্ট লিখতে বা অন্য কোনও স্ক্রিপ্টের প্রক্রিয়াটির অংশ হতে পারেন। তবে, একটি স্ট্যান্ডার্ড ইনস্টল কমান্ড, make install(প্যাকেজ পরিচালকদের পূর্বনির্ধারিত একটি কনভেনশন) থাকায় প্যাকেজগুলি তৈরি করা সত্যিই সহজ হয়ে গেছে। আপনি যদি আর্চলিনাক্স প্যাকেজ তৈরির জন্য পিকেজিবিআইএলডি টেম্পলেটটি দেখে থাকেন তবে দেখতে পাবেন যে প্যাকেজগুলি প্যাকেজগুলি কেবল একটি করে make DESTDIR="$pkgdir/" install। এটি সম্ভবত বেশিরভাগ প্যাকেজগুলির জন্য কাজ করে এবং কিছুটা পরিবর্তন করে more make(এবং অটোলেটগুলি) স্ট্যান্ডার্ড হওয়ার জন্য ধন্যবাদ , প্যাকেজিং সত্যই, সত্যই সহজ।