929 में एक कार्यान्वयन है। भले ही इसे रोजाना हजारों बिल्डों के लिए सफलतापूर्वक (एक कांटा में) उपयोग किया जाता है, लेकिन इसे विलय के लिए नहीं माना जाता था।

929 सिंगल-थ्रेडेड है और इसलिए ccache या अन्य समाधानों की तरह धीमा हो सकता है। इसके अलावा, मुझे लगता है कि इसके बजाय यह एक कमांड लाइन ध्वज होना चाहिए, ताकि इसे बिल्ड परिभाषाओं में बदलाव की आवश्यकता न हो।

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

सिंगल-थ्रेडेड तर्क का जवाब: हाँ, यह सिंगल-थ्रेड लूप में निर्देश जोड़ता है। हकीकत में यह केवल तभी मायने रखता है जब एकल धागे को काम करने से ज्यादा काम मिलता है (यानी एक धागे की तुलना में अधिक नियम खत्म हो सकते हैं (डिप्सलॉग + हैशलॉग + ...))। तभी हैशिंग दर्द होता है। वरना सिंगल थ्रेड लूप वैसे भी जॉब खत्म होने का इंतजार करता है। हमने -j1000 प्रयोगों के साथ भी हैशिंग के साथ व्यस्त निंजा को कभी नहीं देखा। (और फास्ट-फिनिशिंग नियमों के लिए, हैशिंग वैसे भी सुरक्षित समय के लिए दिलचस्प नहीं है।)

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

अंत में, #929 में कार्यान्वयन ऑप्ट-इन है और सुविधा का उपयोग नहीं करने वाले लोगों के लिए बिना किसी कीमत के आता है (इफ-स्टेटमेंट के अलावा)।

हैशिंग जैसे लिंक नियमों के सभी इनपुट महंगे हैं और इसलिए वांछित नहीं हैं, जबकि स्रोत फाइलें और उनकी ज्ञात निर्भरताएं अच्छे उम्मीदवार हैं।

मैं कहूंगा कि लिंकर को इनपुट की हैशिंग विशेष रूप से वांछित है क्योंकि यह अक्सर लिंकिंग को पूरी तरह से छोड़ दिया जा सकता है (उदाहरण के लिए स्वरूपण परिवर्तन या जब टिप्पणियां बदली जाती हैं)। चूंकि ऑब्जेक्ट फाइलों का संकलन टुकड़े-टुकड़े खत्म हो जाता है, हैश गणना तब हो सकती है जब बिल्ड चल रहा हो (जैसा कि आपने बताया)।

यदि यह वास्तव में बहुत धीमा है (उदाहरण के लिए बड़ी स्थिर पुस्तकालयों के साथ), तो हम केवल शुद्ध इनपुट के लिए हैश लागू करने के बारे में सोच सकते हैं, न कि मध्यवर्ती फ़ाइलों के लिए। इससे कम से कम "स्विचिंग गिट शाखाएं पूर्ण पुनर्निर्माण का कारण बनती हैं" मामले को हल करेगी।

इसके अलावा, सुविधा का उपयोग करने के लिए आपको हर समय लगातार ध्वज का उपयोग करना चाहिए। कभी-कभी ही नहीं।

मैं कहूंगा कि यह एक फायदा है: अगर मैं एक ही शाखा पर काम कर रहा हूं और तेजी से पुनरावृति करना चाहता हूं, तो मैं हैश का उपयोग नहीं करूंगा। अगर मैं विभिन्न सुविधाओं की शाखाओं की तुलना कर रहा हूं, तो मैं हैश का उपयोग करूंगा।

इसके अलावा, सुविधा का उपयोग करने के लिए आपको हर समय लगातार ध्वज का उपयोग करना चाहिए। कभी-कभी ही नहीं।

मैं कहूंगा कि यह एक फायदा है: अगर मैं एक ही शाखा पर काम कर रहा हूं और तेजी से पुनरावृति करना चाहता हूं, तो मैं हैश का उपयोग नहीं करूंगा। अगर मैं विभिन्न सुविधाओं की शाखाओं की तुलना कर रहा हूं, तो मैं हैश का उपयोग करूंगा।

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

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

मैंने बड़ी सफलता के साथ काम पर हैशिंग का भी उपयोग किया है। यह #929 पर आधारित है, लेकिन पैच के एक समूह के साथ, जैसा कि https://github.com/moroten/ninja/commits/hashed में देखा जा सकता है। hash_input = 1 चयनित नियमों पर बहुत सुविधाजनक है। मेरी शाखा में अभी भी एक बग है जहां फ़ाइलें stat बहुत बार होती हैं, O(n^2) के बजाय O(n) । बग नकली किनारों से संबंधित है।

एक समस्या यह है कि नकली किनारों को कैसे संभालना है। मैं समूह के लिए नकली किनारों का उपयोग करता हूं जैसे हेडर फाइलें। इसलिए, मेरा कार्यान्वयन नकली किनारों के माध्यम से पुनरावर्ती रूप से पुनरावृत्त होता है। यह #1021 में बग से भी संबंधित है।

एक और विचार हैशिंग को निंजा का प्रथम श्रेणी का सदस्य बनाना है, यानी हैश को बिल्ड लॉग में ले जाना है। SHA256 का उपयोग करना Bazel के दूरस्थ निष्पादन API के लिए समर्थन जोड़ने की दिशा में एक कदम होगा। एक सी ++ कार्यान्वयन https://gitlab.com/bloomberg/recc/ पर पाया जा सकता है। क्या यह बहुत अच्छा नहीं होगा?

दुर्भाग्य से, नकली किनारों के लिए शब्दार्थ को छांटने से शायद पिछड़ी संगतता टूट जाएगी।

इस बीच मैंने क्रोमियम में शाखाओं को स्विच करने के अपने उपयोग के मामले के लिए एक समाधान तैयार किया है (जो विशेष रूप से दर्दनाक है); मेरे द्वारा उपयोग किया जाने वाला छोटा गो प्रोग्राम और स्क्रिप्ट यहाँ है: https://github.com/bromite/mtool

इसे अपने उपयोग के मामलों में अनुकूलित करने के लिए स्वतंत्र महसूस करें, अगर यह क्रोमियम के लिए काम करता है तो मैं शर्त लगाता हूं कि यह छोटी बिल्ड परियोजनाओं के लिए भी काम करेगा (और यह मेरे रनों के लिए नगण्य समय लेता है)। केवल नकारात्मक पक्ष यह है कि यदि आप उस स्क्रिप्ट का उपयोग करते हैं जिसे मैंने वहां प्रकाशित किया है-क्या यह प्रत्येक गिट रिपॉजिटरी मूल निर्देशिका में चारों ओर .mtool फाइलों को लिटेगा, लेकिन वैश्विक gitignore कुछ भी ठीक नहीं हो सकता है।

यह ध्यान रखना दिलचस्प है कि मैं हैशिंग जरूरतों के लिए git ls-files --stage आउटपुट का उपयोग करता हूं; यदि आपका निर्माण उन पर निर्भर करता है तो गिट से हैश को गैर-अनुक्रमित फ़ाइलों से पूछना संभव है (लेकिन कम कुशल)।

फीचर-वार कोई उम्मीद करेगा कि यहां चर्चा की जा रही सुविधा को लागू करने के लिए निंजा आंतरिक रूप से (गिट पर भरोसा किए बिना) और समान प्रदर्शन परिणामों के साथ ऐसा ही कर सकता है।

एक त्वरित रूप से देखने के बाद उन निंजा पैच इनपुट फ़ाइलों के अतिरिक्त कंपाइलर कमांडलाइन हैश नहीं लगते हैं। क्या मुझे कुछ याद आ रहा है?

कमांड लाइन पहले से ही निंजा द्वारा हैश की गई है और बिल्ड लॉग में संग्रहीत है।

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

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

मुझे लगता है कि टाइमस्टैम्प मैच होने पर निंजा पहले से ही सभी काम मान लेता है और छोड़ देता है। तो आपके उदाहरण में यह वैसे भी गलत निर्माण होगा।

मुझे किसी भी उपकरण के बारे में पता नहीं है (शायद मेरी अज्ञानता के कारण) जो एक अलग आउटपुट उत्पन्न करेगा और पिछले टाइमस्टैम्प को बनाए रखेगा। कोई ऐसा क्यों करेगा?

IMHO, हैश चेक को छोड़ना जब टाइमस्टैम्प मैच एक बहुत ही मान्य अनुकूलन है।

हैश चेक बस कुछ "झूठे-गंदे" पुनर्निर्माणों से बचेंगे, जबकि मौजूदा शब्दार्थ को पहले से ही निंजा द्वारा प्रदान किया जाएगा।

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

@rulatir मुझे लगता है कि मैं ज्यादातर समझता हूं कि आप क्या कह रहे हैं :) मुझे लगता है कि यही एक कारण है कि हैश-चेक पर आधारित बाज़ेल और अन्य बिल्ड सिस्टम वास्तव में इन-ट्री लक्ष्य आउटपुट के खिलाफ हैं।

हालाँकि, क्या यह समस्या हल नहीं होगी यदि बिल्ड सिस्टम जाँच करेगा कि क्या लक्ष्य पहले से ज्ञात समय से नए हैं, और यदि आवश्यक हो तो पुनर्निर्माण करें?

@rulatir मुझे लगता है कि मैं ज्यादातर समझता हूं कि आप क्या कह रहे हैं :) मुझे लगता है कि यही एक कारण है कि हैश-चेक पर आधारित बाज़ेल और अन्य बिल्ड सिस्टम वास्तव में इन-ट्री लक्ष्य आउटपुट के खिलाफ हैं।

हैश कैसे निर्भर करता है कि फ़ाइल कहाँ है?

हालाँकि, क्या यह समस्या हल नहीं होगी यदि बिल्ड सिस्टम जाँच करेगा कि क्या लक्ष्य पहले से ज्ञात समय से नए हैं, और यदि आवश्यक हो तो पुनर्निर्माण करें?

मैं समझता हूं कि टाइमस्टैम्प का उपयोग करने का मुख्य लाभ एक अलग डेटाबेस को बनाए रखने की आवश्यकता से बचने में है जो "पहले से ज्ञात" संस्करण हस्ताक्षरों का ट्रैक रखता है। यदि आप उस लाभ को छोड़ना चाहते हैं, तो उन हस्ताक्षरों को हैश क्यों नहीं किया जाना चाहिए?