הגדרות פרוקסי להורדות CMake ExternalProject
זהו את התהליך ואת שלב ההורדה שמאחורי ExternalProject לפני שאתם מניחים שתצורת CMake מוצלחת מוכיחה שהורדות תלויות מאוחרות יותר עוברות באותו מסלול.
CMake מוגדר בהצלחה. הבנייה מתחילה מאוחר יותר, מנסה להוריד תלות חיצונית ונכשלת בפרוקסי. ההצלחה הקודמת לא בהכרח תרגלה את ההורדה הזו כלל.
ExternalProject_Add() יוצר שלבים שיכולים לרוץ בזמן הבנייה. לתהליך שמפעיל את השלבים האלה יכול להיות סביבה שונה מזו של הטרמינל או ה-IDE שהגדירו את הפרויקט הראשי. קל לפספס את ההבדל הזה ב-CI, שבו תצורה והידור יכולים להיות משימות נפרדות.
אתרו את פעולת הרשת
- הורדת URL משתמשת במסלול ההורדה של CMake.
- מקור Git קורא לתעבורת Git עם תצורה נתמכת משלו.
- פקודת
DOWNLOAD_COMMANDמותאמת משתמשת בתוכנית שהפרויקט ציין.
אל תניחו שהגדרת הפרוקסי של תוכנית אחת מגדירה את שלושתן. קראו את הפקודה והשגיאה של השלב שנכשל לפני שתשנו את כתובת ה-URL של התלות.
אם המוריד שנבחר תומך במשתני סביבה של פרוקסי, העבירו אותם לתהליך שמריץ בפועל את השלב הזה. להורדות ציבוריות שהלקוח שלהן מקבל פרוקסי HTTP, רשימת פרוקסי ה-HTTP מציעה מועמדים לנקודות קצה כאשר המסלול הזה מותר. העברת משתנה מטמון רגיל של CMake בשם דומה אינה אוטומטית אותו דבר כמו הגדרת משתנה סביבה של תהליך בן.
שמרו גם על ההבחנה מ-FetchContent: אכלוס התלויות הרגיל שלו מתרחש בזמן התצורה, ולכן מתכון שעובד שם אינו מבסס את הסביבה של שלב בנייה של ExternalProject.
תשובה ישנה שממליצה על מוריד מותאם כדי לעקוף מגבלת הפניה היסטורית אינה הוכחה שכל כשל מודרני זקוק לפקודת הורדה חדשה. בדקו אם השגיאה הנוכחית היא הפניה, אימות פרוקסי, אמון בתעודה או פשוט נגישות. שמרו על גיבוב הארכיון הצפוי ועל אימות TLS בזמן שאתם מתקנים את המסלול הרלוונטי.