Proksio nustatymai CMake ExternalProject atsisiuntimams

CMake sėkmingai sukonfigūruojamas. Kompiliavimas prasideda vėliau, bando atsisiųsti išorinę priklausomybę ir nepavyksta prie proxy. Ankstesnė sėkmė galėjo visai nebandyti to atsisiuntimo.

ExternalProject_Add() sukuria veiksmus, kurie gali vykti kompiliavimo metu. Tų veiksmų paleidimo procesas gali turėti kitą aplinką nei terminalas ar IDE, sukonfigūravę pagrindinį projektą. Šį skirtumą lengva praleisti CI, kur konfigūravimas ir kompiliavimas gali būti atskiri darbai.

Raskite tinklo operaciją

• URL atsisiuntimas naudoja CMake atsisiuntimo kelią.
• Git šaltinis iškviečia Git transportą su savo palaikoma konfigūracija.
• Pasirinktinis DOWNLOAD_COMMAND naudoja bet kurią projekto nurodytą programą.

Nemanote, kad vienos programos proxy nustatymas sukonfigūruoja visus tris. Perskaitykite nepavykusio veiksmo komandą ir klaidą prieš keisdami priklausomybės URL.

Jei pasirinktas atsisiuntėjas palaiko proxy aplinkos kintamuosius, perduokite juos procesui, kuris iš tikrųjų vykdo tą veiksmą. Viešiems atsisiuntimams, kurių klientas priima HTTP proxy, HTTP proxy sąrašas siūlo galinių taškų kandidatus, kai tas kelias leidžiamas. Įprasto panašaus pavadinimo CMake podėlio kintamojo perdavimas automatiškai nėra tas pats, kas vaikinio proceso aplinkos kintamojo nustatymas.

Išsaugokite ir skirtumą nuo FetchContent: įprastas jo priklausomybių užpildymas vyksta konfigūravimo metu, todėl ten veikiantis receptas neįrodo ExternalProject kompiliavimo veiksmo aplinkos.

Senas atsakymas, rekomenduojantis pasirinktinį atsisiuntėją apeiti istorinį peradresavimo apribojimą, nėra įrodymas, kad kiekvienai šiuolaikinei klaidai reikia naujos atsisiuntimo komandos. Patikrinkite, ar dabartinė klaida yra peradresavimas, proxy autentifikavimas, sertifikato pasitikėjimas, ar tiesiog pasiekiamumas. Išsaugokite numatomą archyvo maišą ir TLS patikrinimą taisydami atitinkamą kelią.