CMake ExternalProject डाउनलोडका लागि प्रोक्सी सेटिङहरू
CMake को सफल कन्फिगरेसनले पछिका निर्भरता डाउनलोडहरू एउटै मार्ग लिन्छन् भनी प्रमाणित गर्छ भन्ने मान्नुअघि ExternalProject पछाडिको प्रक्रिया र डाउनलोड चरण पहिचान गर्नुहोस्।
CMake सफलतापूर्वक कन्फिगर हुन्छ। बिल्ड पछि सुरु हुन्छ, बाह्य निर्भरता डाउनलोड गर्न प्रयास गर्छ र प्रोक्सीमा असफल हुन्छ। अघिल्लो सफलताले त्यो डाउनलोड कत्ति पनि चलाएको नहुन सक्छ।
ExternalProject_Add() बिल्डका क्रममा चल्न सक्ने चरणहरू सिर्जना गर्छ। ती चरणहरू सुरु गर्ने प्रक्रियाको वातावरण मुख्य परियोजना कन्फिगर गर्ने टर्मिनल वा IDE भन्दा फरक हुन सक्छ। CI मा यो भिन्नता चुक्नु सजिलो छ, जहाँ कन्फिगरेसन र कम्पाइलेसन छुट्टै काम हुन सक्छन्।
नेटवर्क अपरेसन पहिचान गर्नुहोस्
- URL डाउनलोडले CMake को डाउनलोड मार्ग प्रयोग गर्छ।
- Git स्रोतले आफ्नै समर्थित कन्फिगरेसन भएको Git यातायात बोलाउँछ।
- अनुकूलित
DOWNLOAD_COMMANDले परियोजनाले निर्दिष्ट गरेको जुनसुकै प्रोग्राम प्रयोग गर्छ।
एउटा प्रोग्रामको प्रोक्सी सेटिङले तीनैवटा कन्फिगर गर्छ भनी नमान्नुहोस्। निर्भरताको URL परिवर्तन गर्नुअघि असफल चरणको आदेश र त्रुटि पढ्नुहोस्।
यदि छानिएको डाउनलोडरले प्रोक्सी वातावरण चरहरूलाई समर्थन गर्छ भने, ती चरण साँच्चै चलाउने प्रक्रियालाई दिनुहोस्। जसको क्लाइन्टले HTTP प्रोक्सी स्वीकार गर्छ, त्यस्ता सार्वजनिक डाउनलोडका लागि त्यो मार्ग अनुमति भएमा HTTP प्रोक्सी सूचीले एन्डपोइन्ट उम्मेदवार दिन्छ। समान नामको साधारण CMake क्यास चर पठाउनु स्वतः बाल प्रक्रियाको वातावरण चर सेट गर्नु जस्तै होइन।
FetchContent बाट हुने भिन्नतालाई पनि कायम राख्नुहोस्: यसको सामान्य निर्भरता भर्ने काम कन्फिगरेसनका क्रममा हुन्छ, त्यसैले त्यहाँ काम गर्ने विधिले ExternalProject बिल्ड चरणको वातावरण प्रमाणित गर्दैन।
ऐतिहासिक रिडिरेक्ट सीमालाई छल्न अनुकूलित डाउनलोडर सिफारिस गर्ने पुरानो उत्तर हरेक आधुनिक असफलतालाई नयाँ डाउनलोड आदेश चाहिन्छ भन्ने प्रमाण होइन। वर्तमान त्रुटि रिडिरेक्ट, प्रोक्सी प्रमाणीकरण, प्रमाणपत्रमा विश्वास वा केवल पहुँच हो कि जाँच्नुहोस्। सम्बन्धित मार्ग सुधार्दा अपेक्षित अभिलेख ह्यास र TLS प्रमाणीकरण जोगाउनुहोस्।