CMake ExternalProject ডাউনলোডের জন্য প্রক্সি সেটিংস
CMake-এর সফল কনফিগারেশন পরবর্তী নির্ভরতা ডাউনলোড একই পথ ব্যবহার করে বলে ধরে নেওয়ার আগে ExternalProject-এর পিছনের প্রক্রিয়া ও ডাউনলোড ধাপ চিহ্নিত করুন।
CMake সফলভাবে কনফিগার হয়। বিল্ড পরে শুরু হয়, একটি বাহ্যিক নির্ভরতা ডাউনলোড করার চেষ্টা করে এবং প্রক্সিতে ব্যর্থ হয়। আগের সফলতা ওই ডাউনলোড আদৌ চালায়নি হতে পারে।
ExternalProject_Add() এমন ধাপ তৈরি করে যা বিল্ডের সময় চলতে পারে। ওই ধাপগুলো যে প্রক্রিয়া চালু করে তার পরিবেশ মূল প্রকল্পটি কনফিগার করা টার্মিনাল বা IDE থেকে আলাদা হতে পারে। এই পার্থক্য CI-তে সহজেই চোখ এড়ায়, যেখানে কনফিগারেশন ও কম্পাইলেশন আলাদা কাজ হতে পারে।
নেটওয়ার্ক ক্রিয়াটি চিহ্নিত করুন
- URL ডাউনলোড CMake-এর ডাউনলোড পথ ব্যবহার করে।
- Git উৎস নিজস্ব সমর্থিত কনফিগারেশনসহ Git পরিবহন ডাকে।
- কাস্টম
DOWNLOAD_COMMANDপ্রকল্পটি যে প্রোগ্রাম উল্লেখ করেছে তা ব্যবহার করে।
একটি প্রোগ্রামের প্রক্সি সেটিংস তিনটিই কনফিগার করে বলে ধরে নেবেন না। নির্ভরতার URL বদলানোর আগে ব্যর্থ ধাপের কমান্ড ও ত্রুটি পড়ুন।
যদি নির্বাচিত ডাউনলোডার প্রক্সি পরিবেশ চলক সমর্থন করে, তবে সেগুলো সেই প্রক্রিয়াকে দিন যা সত্যিই ওই ধাপ চালায়। যেসব সর্বজনীন ডাউনলোডের ক্লায়েন্ট HTTP প্রক্সি গ্রহণ করে, সেগুলোর জন্য HTTP প্রক্সি তালিকা ওই পথ অনুমোদিত হলে এন্ডপয়েন্ট প্রার্থী দেয়। একই নামের একটি সাধারণ CMake ক্যাশ চলক পাঠানো স্বয়ংক্রিয়ভাবে সন্তান প্রক্রিয়ার পরিবেশ চলক সেট করার সমান নয়।
FetchContent থেকেও পার্থক্য রাখুন: এর স্বাভাবিক নির্ভরতা পূরণ কনফিগারেশনের সময় ঘটে, তাই সেখানে কাজ করা কোনো রেসিপি ExternalProject বিল্ড ধাপের পরিবেশ প্রতিষ্ঠা করে না।
ঐতিহাসিক রিডাইরেক্ট সীমাবদ্ধতা এড়াতে কাস্টম ডাউনলোডারের পরামর্শ দেওয়া একটি পুরোনো উত্তর প্রমাণ নয় যে প্রতিটি আধুনিক ব্যর্থতার নতুন ডাউনলোড কমান্ড দরকার। বর্তমান ত্রুটিটি রিডাইরেক্ট, প্রক্সি প্রমাণীকরণ, সার্টিফিকেট বিশ্বাস নাকি শুধু পৌঁছানোযোগ্যতা তা যাচাই করুন। প্রাসঙ্গিক পথ ঠিক করার সময় প্রত্যাশিত আর্কাইভ হ্যাশ ও TLS যাচাই বজায় রাখুন।