CMake کامیابی سے ترتیب پاتا ہے۔ بلڈ بعد میں شروع ہوتا ہے، بیرونی انحصار ڈاؤن لوڈ کرنے کی کوشش کرتا ہے اور پراکسی پر ناکام ہوتا ہے۔ پچھلی کامیابی نے وہ ڈاؤن لوڈ شاید بالکل نہ چلایا ہو۔

ExternalProject_Add() ایسے مراحل بناتا ہے جو بلڈ کے دوران چل سکتے ہیں۔ ان مراحل کو شروع کرنے والے عمل کا ماحول مرکزی پروجیکٹ کو ترتیب دینے والے ٹرمینل یا IDE سے مختلف ہو سکتا ہے۔ CI میں یہ فرق چھوڑنا آسان ہے، جہاں ترتیب اور کمپائلیشن الگ کام ہو سکتے ہیں۔

نیٹ ورک آپریشن کی نشاندہی کریں

  • URL ڈاؤن لوڈ CMake کا ڈاؤن لوڈ راستہ استعمال کرتا ہے۔
  • Git ماخذ اپنی معاون ترتیب والی Git ترسیل کو پکارتا ہے۔
  • حسبِ ضرورت DOWNLOAD_COMMAND وہ پروگرام استعمال کرتا ہے جو پروجیکٹ نے بتایا ہو۔

یہ مت فرض کریں کہ ایک پروگرام کی پراکسی ترتیب تینوں کو ترتیب دیتی ہے۔ انحصار کا URL بدلنے سے پہلے ناکام مرحلے کا کمانڈ اور خرابی پڑھیں۔

اگر منتخب ڈاؤن لوڈر پراکسی ماحول کے متغیرات کی حمایت کرتا ہے تو انہیں اس عمل کو دیں جو واقعی وہ مرحلہ چلاتا ہے۔ ان عوامی ڈاؤن لوڈز کے لیے جن کا کلائنٹ HTTP پراکسی قبول کرتا ہے، HTTP پراکسی فہرست اس راستے کی اجازت ہونے پر اینڈ پوائنٹ امیدوار پیش کرتی ہے۔ اسی نام کا عام CMake کیش متغیر بھیجنا خود بخود چائلڈ عمل کا ماحول متغیر مقرر کرنے کے مترادف نہیں۔

FetchContent سے فرق بھی برقرار رکھیں: اس کی معمول کی انحصار بھرائی ترتیب کے دوران ہوتی ہے، اس لیے وہاں کام کرنے والی ترکیب ExternalProject بلڈ مرحلے کا ماحول ثابت نہیں کرتی۔

تاریخی ری ڈائریکٹ حد سے بچنے کے لیے حسبِ ضرورت ڈاؤن لوڈر تجویز کرنے والا پرانا جواب اس بات کا ثبوت نہیں کہ ہر جدید ناکامی کو نئی ڈاؤن لوڈ کمانڈ چاہیے۔ جانچیں کہ موجودہ خرابی ری ڈائریکٹ، پراکسی تصدیق، سرٹیفکیٹ پر اعتماد یا محض رسائی ہے۔ متعلقہ راستہ درست کرتے ہوئے متوقع آرکائیو ہیش اور TLS توثیق برقرار رکھیں۔

متعلقہ مضامین