इन-सोर्स बिल्ड बनाम आउट-ऑफ-सोर्स बिल्ड

Question

मेरे (मुख्य रूप से C ++) विकास में, मैंने लंबे समय से आउट-ऑफ-सोर्स बिल्ड का उपयोग करने का पालन किया है। यह है कि, मेरे स्रोत आम तौर पर एक में बैठता /project/srcनिर्देशिका और एक में रहते हैं बनाता है /project/build/bin/release, /project/build/bin/debugनिर्देशिका। मैंने ऐसा किया है क्योंकि यह मेरे स्रोत निर्देशिकाओं को मध्यवर्ती फ़ाइलों से साफ रखता है, मेरे पास अपने सभी बायनेरिज़ के लिए एक स्थान है, पैकेजिंग आसान है, सफाई आसान है, और संस्करण नियंत्रण आसान है। (क्या मैं कुछ भूल गया?)

मुझे अब एक (बड़ी) परियोजना विरासत में मिली है जो इन-सोर्स बिल्ड का उपयोग करती है। इस प्रकार की संरचना के लिए प्रेरणा क्या है और इसके फायदे क्या हैं? (मैं इंजीनियरिंग-स्तरीय कारणों बनाम व्यक्तिगत वरीयता प्रकार के कारणों से सबसे अधिक चिंतित हूं।)

मैं उम्मीद कर रहा था कि Lakos का "लार्ज-स्केल C ++ सॉफ्टवेयर डिज़ाइन" उस पर तौला जाएगा, लेकिन अगर ऐसा हुआ तो मैं चूक गया।

Comments

क्षमा याचना। मैं "के लिए स्रोत बनाता है" x 'में सुधार के लिए देख रहा हूँ "या" वे' y 'सुनिश्चित करने में मदद करते हैं या "स्वचालित परीक्षण तो' z 'कर सकते हैं। शेख़ी नहीं। मैं विशेष रूप से यहाँ राय की लड़ाई में नहीं जाना चाहता हूँ!

— डिब

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

"इन-सोर्स" बिल्ड से आपका वास्तव में क्या मतलब है? कुछ की तरह /project/src/bin/release, या वास्तव में सभी मध्यवर्ती और आउटपुट फ़ाइलों में /project/src? उत्तरार्द्ध वास्तव में एक गड़बड़ हो सकता है यदि एक दर्जन से अधिक स्रोत फाइलें हैं, तो पूर्व ठीक है।

— डॉक्टर ब्राउन

@ टिबो, यह न केवल मेकफाइल्स के साथ अविश्वसनीय रूप से आसान है, बल्कि अधिकांश आईडीई के साथ भी डिफ़ॉल्ट रूप से प्रतीत होता है (कम से कम जब मैंने कुछ साल पहले अंतिम बार जांच की थी)।

— 1938 में बार्ट वैन इनगेन शेनॉ

@BartvanIngenSchenau सच में? क्या आईडीई आप उपयोग कर रहे हैं जहां यह मामला है? Qt ऐसा नहीं करता है, वास्तव में ऐसा लगता है कि निर्माण को जितना संभव हो सके उतना ही स्रोत से दूर रखा जा सकता है, ग्रहण ऐसा नहीं करता है, आप तर्क दे सकते हैं कि Clion ऐसा करता है, लेकिन केवल एक परिणाम के रूप में main.cpp शुरू में आपकी परियोजना के शीर्ष स्तर पर होने के बावजूद, यह अभी भी उस शीर्ष स्तर पर आपके स्रोत से दूर एक अलग cmake बिल्ड निर्देशिका बनाता है। मेरा मानना ​​है कि MSVS इस संबंध में भी Clion के समान है।

— whn

Answer 1

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

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