إعدادات الوكيل لتنزيلات CMake ExternalProject
حدّد العملية وخطوة التنزيل خلف ExternalProject قبل افتراض أن نجاح تهيئة CMake يثبت أن تنزيلات الاعتماديات اللاحقة تسلك المسار نفسه.
تُهيّئ CMake بنجاح. يبدأ البناء لاحقًا، ويحاول تنزيل اعتمادية خارجية، ويفشل عند الوكيل. النجاح السابق لم يكن بالضرورة قد جرّب ذلك التنزيل إطلاقًا.
ينشئ ExternalProject_Add() خطوات يمكن أن تعمل أثناء البناء. العملية التي تُطلق تلك الخطوات قد يكون لها بيئة مختلفة عن الطرفية أو IDE الذي هيّأ المشروع الرئيسي. هذا الفرق يسهل إغفاله في CI، حيث قد تكون التهيئة والترجمة مهمتين منفصلتين.
حدّد عملية الشبكة
- تنزيل URL يستخدم مسار التنزيل في CMake.
- مصدر Git يستدعي نقل Git بإعداداته المدعومة الخاصة.
- أمر
DOWNLOAD_COMMANDالمخصص يستخدم البرنامج الذي حدده المشروع.
لا تفترض أن إعداد الوكيل لبرنامج واحد يهيّئ الثلاثة جميعًا. اقرأ أمر الخطوة الفاشلة وخطأها قبل تغيير عنوان URL للاعتمادية.
إذا كانت أداة التنزيل المختارة تدعم متغيرات بيئة الوكيل، فمرّرها إلى العملية التي تنفّذ تلك الخطوة فعليًا. للتنزيلات العامة التي يقبل عميلها وكيل HTTP، تقدّم قائمة وكلاء HTTP مرشّحي نقاط نهاية عندما يكون ذلك المسار مسموحًا. تمرير متغير عادي لذاكرة CMake المؤقتة باسم مشابه ليس تلقائيًا مثل تعيين متغير بيئة لعملية فرعية.
احتفظ أيضًا بالتمييز عن FetchContent: عادةً ما يحدث تعبئة الاعتماديات فيه أثناء التهيئة، لذا فإن وصفة تنجح هناك لا تثبت بيئة خطوة بناء ExternalProject.
إجابة قديمة توصي بأداة تنزيل مخصصة للالتفاف على قيد إعادة توجيه تاريخي ليست دليلًا على أن كل فشل حديث يحتاج أمر تنزيل جديدًا. تحقق مما إذا كان الخطأ الحالي إعادة توجيه أو مصادقة وكيل أو ثقة في الشهادة أو مجرد إمكانية وصول. حافظ على تجزئة الأرشيف المتوقعة والتحقق من TLS أثناء إصلاح المسار المعني.