Proksegaj agordoj por elŝutoj de CMake ExternalProject

CMake agordiĝas sukcese. La konstruado komenciĝas pli poste, provas elŝuti eksteran dependaĵon kaj malsukcesas ĉe la proksejo. La pli frua sukceso eble tute ne elprovigis tiun elŝuton.

ExternalProject_Add() kreas paŝojn, kiuj povas ruliĝi dum la konstruado. La procezo, kiu lanĉas tiujn paŝojn, povas havi alian medion ol la terminalo aŭ IDE, kiu agordis la ĉefan projekton. Tiu diferenco facile mankas en CI, kie agordo kaj kompilado povas esti apartaj taskoj.

Identigu la retan operacion

• URL-elŝuto uzas la elŝutan vojon de CMake.
• Git-fonto alvokas Git-transportilon kun propra subtenata agordo.
• Propra DOWNLOAD_COMMAND uzas tiun programon, kiun la projekto indikis.

Ne supozu, ke la prokseja agordo por unu programo agordas ĉiujn tri. Legu la komandon kaj eraron de la malsukcesa paŝo antaŭ ol ŝanĝi la URL de la dependaĵo.

Se la elektita elŝutilo subtenas prokseajn medivariablojn, donu ilin al la procezo, kiu efektive plenumas tiun paŝon. Por publikaj elŝutoj, kies kliento akceptas HTTP-proksejon, la HTTP-prokseja listo proponas finpunktojn, kiam tiu vojo estas permesita. Transdoni ordinaran kaŝmemoran variablon de CMake kun simila nomo ne estas aŭtomate la samo kiel agordi medivariablon de infana procezo.

Konservu ankaŭ la distingon de FetchContent: ĝia kutima plenigo de dependaĵoj okazas dum agordo, do recepto, kiu funkcias tie, ne establas la medion de konstrupaŝo de ExternalProject.

Malnova respondo rekomendanta propran elŝutilon por ĉirkaŭiri historian alidirektan limigon ne estas pruvo, ke ĉiu moderna malsukceso bezonas novan elŝutan komandon. Kontrolu, ĉu la nuna eraro estas alidirekto, prokseja aŭtentigo, atestila fido aŭ simple atingeblo. Konservu la atendatan arĥivan haketon kaj TLS-validadon dum vi riparas la koncernan vojon.