Xcode Clean Build Folder बनाम DerivedData डिलीट करना

फ़र्क़ दायरे का है, गहराई का नहीं

Product > Clean Build Folder (Shift-Command-K) उसी प्रोजेक्ट और स्कीम के अंदर काम करता है जो अभी खुली है। यह उस संदर्भ के कंपाइल किए गए प्रोडक्ट और इंटरमीडिएट फ़ाइलें हटा देता है, ताकि अगला बिल्ड सोर्स से शुरू हो। इसका दायरा एक प्रोजेक्ट तक सीमित है, और जिन चीज़ों को दोबारा बनाना महँगा पड़ता है, उन्हें यह जानबूझकर रहने देता है।

DerivedData वह मुख्य डायरेक्टरी है जिसे डिफ़ॉल्ट स्थान इस्तेमाल करने वाले सभी प्रोजेक्ट साझा करते हैं — ~/Library/Developer/Xcode/DerivedData, जिसमें आपके अब तक खोले गए हर प्रोजेक्ट या वर्कस्पेस का एक सबफ़ोल्डर होता है। एक सबफ़ोल्डर डिलीट करने से ठीक वही प्रोजेक्ट रीसेट होता है। पूरी डायरेक्टरी डिलीट करने पर आपका हर प्रोजेक्ट अगली बार खुलने पर दोबारा बिल्ड और इंडेक्स होगा।

इसलिए इन दोनों को “हल्की सफ़ाई” बनाम “गहरी सफ़ाई” कहना सही नहीं है। Clean Build Folder का दायरा छोटा है और कीमत कम; DerivedData डिलीट करने का दायरा बड़ा है और इसकी कीमत इंडेक्स खोना है। कौन-सा सही है, यह पूरी तरह इस पर निर्भर करता है कि गड़बड़ी बिल्ड प्रोडक्ट के अंदर है या उनके बाहर।

बिल्ड टूटे तो छोटे दायरे से शुरू करें

अगर गड़बड़ी ब्रांच बदलने, बिल्ड कॉन्फ़िगरेशन बदलने या रिसोर्स फ़ाइलें एडिट करने के ठीक बाद दिखी है, तो चल रहा ऐप बंद करें और पहले Clean Build Folder इस्तेमाल करें। यह सबसे सस्ता रीसेट है, इंडेक्स को बचाए रखता है, और आपको एक ही बिल्ड में काम पर लौटा देता है — एक बिल्ड और फिर कई मिनट की इंडेक्सिंग में नहीं।

अगर लक्षण असल में बिल्ड प्रोडक्ट से जुड़े नहीं हैं, तो अगला कदम उठाएँ और उस प्रोजेक्ट का DerivedData फ़ोल्डर डिलीट करें: जैसे Xcode उस कोड के लिए एरर दिखाए जिसे आप ठीक कर चुके हैं, Jump to Definition ग़लत जगह ले जाए, या कोड कंप्लीशन आपके अपने टाइप पहचानना बंद कर दे। ये इंडेक्स के लक्षण हैं, और Clean Build Folder इंडेक्स को नहीं छूता।

एक ख़ास मामला जानने लायक़ है, क्योंकि आम तौर पर इसी वजह से “क्लीन किया, कोई फ़ायदा नहीं हुआ” बदलकर “DerivedData डिलीट किया और ठीक हो गया” बन जाता है: प्रीकंपाइल्ड मॉड्यूल कैश (ModuleCache.noindex) DerivedData की रूट में रहता है, किसी प्रोजेक्ट के सबफ़ोल्डर में नहीं। Clean Build Folder वहाँ तक कभी नहीं पहुँचता। SDK या टूलचेन बदलने के बाद मॉड्यूल कैश पुराना पड़ जाए, तो उसे हटाने से ही एरर दूर होता है।

इनमें से कोई भी कमांड आपके सोर्स या डिपेंडेंसी का असली बग ठीक नहीं करता। अगर क्लीन बिल्ड के बाद भी हूबहू वही एरर आता है, तो सफ़ाई रोकें और कंपाइलर का संदेश पढ़ें — वजह प्रोजेक्ट सेटिंग, Package.resolved, चुने गए SDK या ख़ुद कोड में है।

दोनों में से कोई भी डिस्क सफ़ाई का तरीका नहीं है

Clean Build Folder गड़बड़ी पहचानने का टूल है, जो संयोग से कुछ बाइट भी ख़ाली कर देता है। यह मौजूदा प्रोजेक्ट की कुछ जगह लौटा सकता है, लेकिन बाक़ी सभी प्रोजेक्ट के बिल्ड प्रोडक्ट, हर इंडेक्स और मॉड्यूल कैश ठीक वहीं के वहीं रहते हैं। डिस्क की जगह वापस पाने के लिए इसे चलाना ग़लत चीज़ पर ध्यान देना है।

अगर असली मक़सद जगह है, तो उल्टी दिशा से चलें: पहले DerivedData के सबफ़ोल्डर मापें, फिर उन प्रोजेक्ट के फ़ोल्डर डिलीट करें जिन्हें आपने महीनों से नहीं खोला। दसियों गीगाबाइट आम तौर पर वहीं होते हैं — ऐसे क्लोन में जिन्हें आपने एक बार बिल्ड किया और फिर कभी उन पर नहीं लौटे।

शुरुआत rm -rf से न करें। Finder में आप चुने हुए फ़ोल्डर रद्दी में डाल सकते हैं, जहाँ से रद्दी ख़ाली करने तक उन्हें वापस लाया जा सकता है — और यह फ़र्क़ तब बहुत मायने रखता है, जब आप पहली बार किसी ऐसे प्रोजेक्ट का फ़ोल्डर डिलीट कर दें जो ठीक उसी समय बिल्ड हो रहा हो। ऑटोमेशन के लिए टर्मिनल ठीक है, लेकिन तभी जब आप सटीक पाथ पक्का कर चुके हों।

किसी आँकड़े पर भरोसा करने के बजाय नतीजा जाँचें

कुछ भी करने से पहले DerivedData का आकार लिख लें, दोनों में से ठीक एक विकल्प अपनाएँ, फिर दोबारा मापें। Clean Build Folder के बाद मौजूदा स्कीम बिल्ड करें। DerivedData फ़ोल्डर डिलीट करने के बाद Xcode खोलें और पहला बिल्ड व इंडेक्सिंग पूरी होने का इंतज़ार करें।

इस क्रम में करने से साफ़ दिखता है कि कितनी जगह वापस मिली और उसके लिए क्या कीमत चुकानी पड़ी। उम्मीद करने लायक़ कोई सार्वभौमिक आँकड़ा नहीं है: नतीजा इस पर निर्भर है कि उस Mac पर कितने प्रोजेक्ट, कॉन्फ़िगरेशन और आर्किटेक्चर के लिए बिल्ड किए गए हैं।

कब कौन-सा कदम उठाएँ

यह तालिका दायरा बताती है, गीगाबाइट की कोई पक्की संख्या नहीं। पहले और बाद में अपना Mac ख़ुद मापें।

FAQ