VPN के ज़रिये दूर से C++ बिल्ड: टूलचेन होस्ट पर ही रखें
शेयर माउंट करना दूर से बिल्ड करने के बराबर नहीं है। जाँचें कि कौन-सा होस्ट जवाब देता है, कौन-सा कंपाइलर चलता है, और डीबगर तथा नेटवर्क कहाँ रहते हैं।
शेयर माउंट हो जाता है, एडिटर फ़ाइल खोल देता है, और बिल्ड फिर भी लैपटॉप पर ही चलता है। कोई त्रुटि नहीं दिखती, और यही बात इसे उलझन भरा बनाती है। दूर का पाथ दूर की टूलचेन नहीं होता, और जो एडिटर माउंट के ज़रिये फ़ाइल पढ़ सकता है वह उस पर स्थानीय कंपाइलर को ख़ुशी से बुला लेगा। हल यह है कि सिर्फ़ बाइट्स नहीं, वर्कस्पेस हटाया जाए।
माउंट की गई डायरेक्टरी वर्कस्पेस नहीं होती
SSH या SMB से माउंट करने पर आपको एक पाथ मिलता है। कंपाइलर, बिल्ड सिस्टम और डीबगर दूर की ओर से आते हैं या नहीं, यह इस पर निर्भर है कि एडिटर उन्हें कहाँ चलाने का फ़ैसला करता है। कई सेटअप दूर की फ़ाइलें पढ़कर उन्हें स्थानीय रूप से कंपाइल करते हैं, फिर ऐसी हेडर फ़ाइल पर विफल हो जाते हैं जो सिर्फ़ सर्वर पर मौजूद है।
लक्षण सूक्ष्म है: बिल्ड आंशिक परिणामों के साथ सफल होता है, या ऐसे include पाथ पर टूट जाता है जो एडिटर में सही दिखता है।
साबित करें कि कौन-सा होस्ट जवाब देता है
माउंट के बजाय असली रिमोट सेशन से जुड़ें, फिर उस सेशन वाले टर्मिनल में तीन केवल-पढ़ने वाले कमांड चलाएँ। VS Code की SSH गाइड दस्तावेज़ित करती है कि जुड़ी हुई रिमोट विंडो का टर्मिनल रिमोट होस्ट पर चलता है और वही सेशन डीबगिंग भी ले जाता है। अगर संस्था रिमोट कंपोनेंट सीमित करती है तो पहले उनकी मंज़ूरी लें।
hostname उस मशीन का नाम बताता है जिस पर आप हैं, pwd दिखाता है कि वर्कस्पेस असल में कहाँ है, और command -v c++ वह कंपाइलर छापता है जो शेल चलाता। तीनों जवाबों को लैपटॉप नहीं, सर्वर का वर्णन करना चाहिए।
वे यह साबित नहीं करते कि वर्ज़न या बिल्ड कॉन्फ़िगरेशन सही है। उसे अलग चरण के रूप में प्रोजेक्ट के अपने निर्देशों से मिलाएँ।
एक बदलाव को बिल्ड और डीबग से होकर देखें
रिमोट वर्कस्पेस में छोटा बदलाव करें और उसे वहीं सहेजें। उसी डायरेक्टरी से दस्तावेज़ी बिल्ड चलाएँ और पुष्टि करें कि आउटपुट आपका बदलाव दिखाता है, कहीं और रखी पुरानी कॉपी नहीं। फिर उसी रिमोट सेशन से डीबगर शुरू करें, जिसमें बाइनरी पाथ और वर्किंग डायरेक्टरी सर्वर के बिल्ड ट्री की ओर इशारा करें। स्रोत पाथ मिलना ज़रूरी है, क्योंकि जो डीबगर आपके बदलाव को लैपटॉप पाथ से जोड़ता है वह दूसरी फ़ाइल डीबग करता है।
अगर डीबग लक्ष्य आपकी स्थानीय होम डायरेक्टरी से शुरू होने वाले पाथ बताए, तो लॉन्च कॉन्फ़िगरेशन अब भी स्थानीय सोच रहा है।
नेटवर्क निर्भरताएँ होस्ट के पास ही रहती हैं
बिल्ड होस्ट पर शुरू हुआ पैकेज फ़ेच, git ऑपरेशन या टेस्ट रन उसी होस्ट का नेटवर्क और क्रेडेंशियल इस्तेमाल करता है, आपके लैपटॉप का VPN सेशन नहीं। लैपटॉप किसी निजी पैकेज मिरर तक पहुँच जाए, इससे यह नहीं पता चलता कि सर्वर पहुँच सकता है या नहीं। अगर बिल्ड को रजिस्ट्री चाहिए, तो सर्वर को उस तक रूट चाहिए, और यह एडिटर सेटिंग नहीं, फ़ायरवॉल की बात है।
उलटी दिशा में भी यही टेस्ट ऐप्लिकेशन पर लागू होता है। ब्राउज़र से सर्वर पर किसी सेवा तक पहुँचना अलग कनेक्शन है जिसके लिए मंज़ूर निजी पाथ या सीमित फ़ॉरवर्ड चाहिए, खुला लिसनर नहीं।
काम खोए बिना डिस्कनेक्ट करें
कनेक्शन गिरने से पहले सहेजें और commit करें, या कम से कम वर्किंग ट्री दर्ज करें। रिमोट एडिटिंग सेशन यह वादा नहीं करता कि चल रहा बिल्ड या बिना सहेजा बफ़र नेटवर्क बाधा से बचेगा। जो कुछ आपके सेशन से ज़्यादा टिकना चाहिए उसके लिए प्रोजेक्ट का समर्थित जॉब या सेशन वर्कफ़्लो इस्तेमाल करें।
तब काम का बँटवारा साफ़ है: लैपटॉप एक इंटरफ़ेस है, सर्वर वर्कस्पेस और टूलचेन का मालिक है, और VPN रूट देता है। फ़ाइलें हटाना और बिल्ड हटाना दो अलग फ़ैसले हैं।