একটি build wrapper আপনাকে CMake আর্গুমেন্ট যোগ করতে দিতে পারে, কিন্তু CMake চালু করতে যে পরিবেশ ব্যবহার হয় তা লুকিয়ে রাখে। একটি আগাম project hook আপনাকে configure প্রক্রিয়ার প্রক্সি মান সরবরাহ করার একটি জায়গা দেয়।

একটি ছোট ফাইল স্থিতিশীল, সম্পূর্ণ (absolute) পাথে সংরক্ষণ করুন, উদাহরণস্বরূপ /home/alex/cmake/proxy-env.cmake:

set(ENV{http_proxy} "http://proxy.example:8080")
set(ENV{https_proxy} "http://proxy.example:8080")

সেই ফাইলটি configuration-এ পাঠান:

cmake -S . -B build -DCMAKE_PROJECT_INCLUDE_BEFORE=/home/alex/cmake/proxy-env.cmake

CMAKE_PROJECT_INCLUDE_BEFORE প্রতিটি project() কলে ফাইলটি শুরুতে অন্তর্ভুক্ত করে। তাই এটি CMAKE_PROJECT_INCLUDE-এর আগে চলে, যা ওই কলের শেষে চলে। ভাষা সেটআপ বা একটি nested project যখন রুট দরকার করে তখন এই পার্থক্যটি গুরুত্বপূর্ণ।

configure সময়ে একটি পাবলিক intermediary দিয়ে অনুমোদিত পাবলিক ডাউনলোডের জন্য, HTTP প্রক্সি তালিকা থেকে HTTP URL মান বেছে নিন। hook তবুও তার আগে চলা কাজকে প্রভাবিত করতে পারে না, যার মধ্যে প্রথম project() কলের আগের ডাউনলোডও আছে। এটি স্থায়ী operating-system পরিবেশ সেটিংও লেখে না।

এই CMake প্রক্রিয়া পরে যে প্রক্রিয়াগুলো চালু করে তারা মানগুলো উত্তরাধিকারসূত্রে পেতে পারে, যদি তাদের network client তা সমর্থন করে। পরে আলাদাভাবে চালু করা build-এর নিজস্ব পরিবেশ থাকে। ওই build পর্যায়ে বিলম্বিত ডাউনলোডকেও সেখানে প্রক্সি পেতে হবে।

hook ফাইলে ব্যক্তিগত সংযোগের বিবরণ থাকলে তা পাবলিক source tree-এর বাইরে রাখুন। -D আর্গুমেন্ট hook path-টি CMake ভেরিয়েবল হিসেবে সংরক্ষণ করে; set(ENV{...}) চলমান প্রক্রিয়ার পরিবেশ বদলায়, cache ভেরিয়েবলকে প্রক্সি সেটিংয়ে পরিণত করে না।

সম্পর্কিত নিবন্ধ