কেন "মেক" ইন ইনক্রিমেন্টাল বিল্ডগুলি হ্যাশিং অ্যালগরিদম ব্যবহার করে না?

Question

আমি একটি শিক্ষানবিস makeএবং আমি কখন ব্যবহার করব তা নিয়ে ভাবছি make clean।

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

যাইহোক, আমি make cleanঅন্যান্য স্ট্যাক এক্সচেঞ্জ প্রশ্নগুলি থেকে "কখন ব্যবহার করব " প্রশ্নের উত্তর পেয়েছি তবে আমার অন্য প্রশ্নটি হ'ল:

makeউদাহরণস্বরূপ, SHA-1 এ নয় কেন ফাইল টাইমস্ট্যাম্পগুলিতে নির্ভর করে বর্ধিত বিল্ডগুলি ব্যবহার করে ? উদাহরণস্বরূপ, গিট দেখায় যে SHA-1 ব্যবহার করে কোনও ফাইল পরিবর্তন করা হয়েছিল কিনা তা আমরা সফলভাবে নির্ধারণ করতে পারি।
এটা কি গতির সমস্যার জন্য?

Comments

make70 এর দশকে তৈরি হয়েছিল। 90 এর দশকে SHA-1 তৈরি হয়েছিল। গিট 00 এর দশকে তৈরি হয়েছিল। আপনি যা চান তা সর্বশেষ হ'ল কিছু অস্পষ্ট বিল্ডগুলির জন্য যা হঠাৎ ব্যর্থ হওয়ার জন্য 30 বছর ধরে কাজ করে যাচ্ছিল কারণ কেউ চেষ্টা করেছেন এবং পরীক্ষিত সিস্টেমের সাহায্যে সমস্ত আধুনিক হওয়ার সিদ্ধান্ত নিয়েছেন।

— সাধারণ

ফাইলগুলি সারাক্ষণ হ্যাশ করা ধীর। আমি মনে করি গিট পরিবর্তিত ফাইলগুলির জন্য চেকগুলি অপ্টিমাইজ করতে ফাইল সিস্টেম মেটাডেটাও ব্যবহার করে।

— কোডসইনচওস

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

— ডক ব্রাউন

@ অর্দৌস: মজাদার, তবে এটি কি এখানে প্রাসঙ্গিক? সফ্টওয়্যার মরিচা না; কেউ আশেপাশের পরিবেশে কিছু পরিবর্তন করেছে কারণ এটি প্রদান করে। যদি না তারা না করে তবে এই ক্ষেত্রে এটি এখনও কাজ করা উচিত।

— রবার্ট হার্ভে

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

— সাধারণ

Answer 1

একটি সুস্পষ্ট (এবং তর্কযুক্ত যুক্তিযুক্ত) সমস্যাটি হ'ল বিল্ড সিস্টেমকে শেষ বিল্ডের জন্য ব্যবহৃত ফাইলগুলির হ্যাশগুলির রেকর্ড রাখতে হবে। এই সমস্যাটি অবশ্যই সমাধান করা যেতে পারে, যখন সময়-স্ট্যাম্পের তথ্য ফাইল-সিস্টেমে ইতিমধ্যে উপস্থিত থাকে তখন এটিকে সাইড স্টোরেজ প্রয়োজন।

আরও গুরুতর, যদিও, হ্যাশ একই শব্দার্থবিজ্ঞান প্রকাশ করবে না। আপনি যদি জানেন যে ফাইল টি হ্যাশ এইচ _{1 এর} সাথে নির্ভরশীলতা ডি থেকে তৈরি হয়েছিল এবং তারপরে জানতে পারেন যে ডি এখন এইচ _{2 এ} চলেছে , আপনার কি টি পুনর্নির্মাণ করা উচিত ? সম্ভবত হ্যাঁ, তবে এটি এমনও হতে পারে যে এইচ ₂ আসলে ফাইলটির একটি পুরানো সংস্করণ বোঝায় । সময়-স্ট্যাম্পগুলি একটি অর্ডারকে সংজ্ঞায়িত করে যখন হ্যাশগুলি কেবল সাম্যের জন্য তুলনীয়।

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

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

Comments

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

— axel

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

— btilly

এখানে ম্যাপিং অনেকের পক্ষে এক নয়, এটি একের পর এক। যদি Dএখন হ্যাশ হয় H2, এবং আপনার T2থেকে কিছু আউটপুট নির্মিত না হয় D@H2, আপনাকে এটি উত্পাদন এবং সঞ্চয় করতে হবে। তারপর, নির্বিশেষে কি অর্ডার Dমধ্যে স্যুইচ করতে H1এবং H2রাজ্যের, আপনি ক্যাশে আউটপুট ব্যবহার করতে সক্ষম হবে।

— আসাদ সাইদুদ্দীন

Answer 2

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

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

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

Comments

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

— আসাদ সাইদুদ্দিন

Answer 3

বিল্ড-সিস্টেমে হ্যাশ বনাম টাইমস্ট্যাম্প সম্পর্কে কয়েকটি পয়েন্ট:

1. আপনি যখন কোনও ফাইল চেকআউট করেন, টাইমস্ট্যাম্পটি বর্তমান সময়ে আপডেট করা উচিত, যা পুনর্নির্মাণের সূত্রপাত করে। আপনার সহকর্মী যা বর্ণনা করে তা সাধারণত টাইমস্ট্যাম্প সিস্টেমগুলির ব্যর্থতা মোড নয়।
2. টাইমস্ট্যাম্পগুলি হ্যাশগুলির তুলনায় সামান্য দ্রুত। একটি টাইমস্ট্যাম্প সিস্টেমে কেবল টাইমস্ট্যাম্প পরীক্ষা করতে হয়, যেখানে একটি হ্যাশ সিস্টেম অবশ্যই টাইমস্ট্যাম্প এবং তারপরে সম্ভাব্য হ্যাশ পরীক্ষা করে।
3. মেকটি হালকা ওজন এবং স্বনির্ভর হওয়ার জন্য ডিজাইন করা হয়েছে। (২) কাটিয়ে উঠতে, হ্যাশ ভিত্তিক সিস্টেমগুলি সাধারণত হ্যাশগুলি পরীক্ষা করার জন্য একটি পটভূমি প্রক্রিয়া চালিত করে (যেমন ফেসবুকের ওয়াচম্যান )। এটি মেকের ডিজাইন লক্ষ্যগুলি (এবং ইতিহাস) এর সাথে পাল্টা।
4. যখন টাইমস্ট্যাম্প পরিবর্তিত হয় তবে বিষয়বস্তুতে পরিবর্তন হয় না তখন হ্যাশগুলি অপ্রয়োজনীয় পুনর্নির্মাণগুলি প্রতিরোধ করে। প্রায়শই এটি হ্যাশ গণনার জন্য ব্যয় করে off
5. হ্যাশগুলি প্রকল্প এবং একটি নেটওয়ার্ক জুড়ে আর্টফ্যাক্ট ক্যাশেগুলি ভাগ করে নিতে সক্ষম করে। আবার, এটি কম্পিউটিং হ্যাশগুলির ব্যয়ের চেয়ে বেশি অফসেট করে।
6. আধুনিক হ্যাশ-ভিত্তিক বিল্ড-সিস্টেমগুলির মধ্যে বাজেল (গুগল) এবং বাক (ফেসবুক) অন্তর্ভুক্ত রয়েছে।
7. বেশিরভাগ বিকাশকারীদের একটি হ্যাশ-ভিত্তিক সিস্টেম ব্যবহার করা বিবেচনা করা উচিত, যেহেতু তাদের মেক ডিজাইন করা হয়েছে তার মতো প্রয়োজনীয়তা নেই।