تنظیمات پروکسی برای دانلودهای CMake ExternalProject

CMake با موفقیت پیکربندی می‌شود. ساخت بعداً آغاز می‌شود، تلاش می‌کند یک وابستگی خارجی را دانلود کند و در پروکسی شکست می‌خورد. موفقیت پیشین لزوماً آن دانلود را اصلاً اجرا نکرده بود.

ExternalProject_Add() مراحلی می‌سازد که می‌توانند هنگام ساخت اجرا شوند. فرایندی که آن مراحل را آغاز می‌کند می‌تواند محیطی متفاوت از ترمینال یا IDEای داشته باشد که پروژه اصلی را پیکربندی کرده است. این تفاوت در CI به‌راحتی از چشم می‌افتد، جایی که پیکربندی و کامپایل ممکن است کارهای جداگانه باشند.

عملیات شبکه را مشخص کنید

• دانلود از طریق URL از مسیر دانلود CMake استفاده می‌کند.
• منبع Git یک ترابری Git با پیکربندی پشتیبانی‌شده خودش را فرامی‌خواند.
• یک DOWNLOAD_COMMAND سفارشی از برنامه‌ای استفاده می‌کند که پروژه مشخص کرده است.

فرض نکنید تنظیم پروکسی برای یک برنامه هر سه را پیکربندی می‌کند. پیش از تغییر URL وابستگی، فرمان و خطای مرحله شکست‌خورده را بخوانید.

اگر دانلودکننده انتخاب‌شده متغیرهای محیطی پروکسی را پشتیبانی می‌کند، آن‌ها را به فرایندی بدهید که واقعاً آن مرحله را اجرا می‌کند. برای دانلودهای عمومی که کلاینتشان پروکسی HTTP را می‌پذیرد، فهرست پروکسی HTTP وقتی این مسیر مجاز است نامزدهای نقطه پایانی ارائه می‌دهد. گذراندن یک متغیر کش معمولی CMake با نام مشابه، به‌طور خودکار همان تنظیم متغیر محیطی فرایند فرزند نیست.

تمایز با FetchContent را نیز حفظ کنید: پرکردن معمول وابستگی‌هایش هنگام پیکربندی رخ می‌دهد، پس دستوری که آنجا کار می‌کند محیط یک مرحله ساخت ExternalProject را اثبات نمی‌کند.

پاسخ قدیمی‌ای که دانلودکننده سفارشی را برای دور زدن محدودیت تاریخی تغییر مسیر توصیه می‌کند، شاهدی بر این نیست که هر خطای امروزی به فرمان دانلود جدید نیاز دارد. بررسی کنید که خطای کنونی تغییر مسیر، احراز هویت پروکسی، اعتماد به گواهی یا صرفاً دسترسی‌پذیری است. هنگام اصلاح مسیر مربوطه، هش مورد انتظار آرشیو و اعتبارسنجی TLS را حفظ کنید.