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