CMake-ը հաջողությամբ կարգավորվում է։ Կառուցումը սկսվում է ավելի ուշ, փորձում է ներբեռնել արտաքին կախվածություն և ձախողվում է փրոքսիի վրա։ Նախորդ հաջողությունը կարող է ընդհանրապես չփորձարկած լինել այդ ներբեռնումը։

ExternalProject_Add() ստեղծում է քայլեր, որոնք կարող են գործարկվել կառուցման ընթացքում։ Այդ քայլերը սկսող գործընթացի միջավայրը կարող է տարբերվել հիմնական նախագիծը կարգավորած տերմինալից կամ IDE-ից։ Այս տարբերությունը հեշտ է բաց թողնել CI-ում, որտեղ կարգավորումն ու կոմպիլյացիան կարող են առանձին աշխատանքներ լինել։

Գտեք ցանցային գործողությունը

Չենթադրեք, որ մեկ ծրագրի փրոքսի կարգավորումը կարգավորում է բոլոր երեքը։ Կարդացեք ձախողված քայլի հրամանն ու սխալը՝ նախքան կախվածության URL-ը փոխելը։

Եթե ընտրված ներբեռնիչը աջակցում է փրոքսիի միջավայրի փոփոխականներին, տրամադրեք դրանք այն գործընթացին, որն իրականում կատարում է այդ քայլը։ Հանրային ներբեռնումների համար, որոնց հաճախորդը ընդունում է HTTP փրոքսի, HTTP փրոքսիների ցանկը առաջարկում է վերջնակետերի թեկնածուներ, երբ այդ ուղին թույլատրված է։ Նման անունով սովորական CMake քեշի փոփոխական փոխանցելը ինքնաբերաբար նույնը չէ, ինչ ենթական գործընթացի միջավայրի փոփոխական սահմանելը։

Պահպանեք նաև տարբերությունը FetchContent-ից․ նրա սովորական կախվածությունների լրացումը տեղի է ունենում կարգավորման ընթացքում, ուստի այնտեղ աշխատող բաղադրատոմսը չի հաստատում ExternalProject կառուցման քայլի միջավայրը։

Հին պատասխանը, որ խորհուրդ է տալիս հատուկ ներբեռնիչ՝ պատմական վերահասցեավորման սահմանափակումը շրջանցելու համար, ապացույց չէ, որ յուրաքանչյուր ժամանակակից ձախողում նոր ներբեռնման հրաման է պահանջում։ Ստուգեք՝ արդյոք ընթացիկ սխալը վերահասցեավորում է, փրոքսիի նույնականացում, վկայագրի վստահություն, թե պարզ հասանելիություն։ Պահպանեք արխիվի սպասվող հեշը և TLS վավերացումը՝ ուղին շտկելիս։

Առնչվող հոդվածներ