Mipangilio ya proksi kwa upakuaji wa CMake ExternalProject

CMake hujisanidi kwa mafanikio. Ujenzi huanza baadaye, hujaribu kupakua kitegemezi cha nje, na hushindwa kwenye proksi. Mafanikio ya awali huenda hayakufanya kabisa upakuaji huo.

ExternalProject_Add() huunda hatua zinazoweza kuendeshwa wakati wa ujenzi. Mchakato unaoanzisha hatua hizo unaweza kuwa na mazingira tofauti na terminali au IDE iliyosanidi mradi mkuu. Tofauti hiyo ni rahisi kukosa katika CI, ambapo usanidi na ujumuishaji vinaweza kuwa kazi tofauti.

Tambua operesheni ya mtandao

• Upakuaji wa URL hutumia njia ya upakuaji ya CMake.
• Chanzo cha Git huita usafirishaji wa Git wenye usanidi wake unaotumika.
• DOWNLOAD_COMMAND maalum hutumia programu yoyote iliyotajwa na mradi.

Usidhani kuwa mipangilio ya proksi ya programu moja inasanidi zote tatu. Soma amri na hitilafu ya hatua iliyoshindwa kabla ya kubadilisha URL ya kitegemezi.

Ikiwa kipakuzi kilichochaguliwa kinatumia vigeu vya mazingira vya proksi, vipe mchakato unaotekeleza hatua hiyo kwa kweli. Kwa upakuaji wa umma ambao mteja wake unakubali proksi ya HTTP, orodha ya proksi za HTTP hutoa wagombea wa vituo vya mwisho wakati njia hiyo inaruhusiwa. Kupitisha kigeu cha kawaida cha akiba cha CMake chenye jina kama hilo si sawa moja kwa moja na kuweka kigeu cha mazingira cha mchakato mtoto.

Hifadhi pia tofauti na FetchContent: ujazaji wake wa kawaida wa vitegemezi hufanyika wakati wa usanidi, kwa hivyo mapishi yanayofanya kazi hapo hayathibitishi mazingira ya hatua ya ujenzi ya ExternalProject.

Jibu la zamani linalopendekeza kipakuzi maalum ili kuepuka kikwazo cha kihistoria cha uelekezaji upya si ushahidi kwamba kila hitilafu ya kisasa inahitaji amri mpya ya upakuaji. Angalia kama hitilafu ya sasa ni uelekezaji upya, uthibitishaji wa proksi, uaminifu wa cheti au ufikivu tu. Hifadhi hashi inayotarajiwa ya kumbukumbu na uthibitishaji wa TLS unaporekebisha njia husika.