Una build fuori sorgente è una build che può trovarsi in qualsiasi directory diversa dalla directory di origine
Ho un progetto che contiene percorsi relativi ad alcuni file di risorse, necessari al runtime, che si trovano vicino alla directory di origine.
Ma quando costruisco il progetto in una cartella arbitraria, i file di risorse sono (ovviamente) non trovati.
Qual è il modo corretto di fornire percorsi ai file di risorse?
Suppongo che il tuo programma sia codificato in un linguaggio compilato (cioè un linguaggio implementato in un compilatore) come C o C ++ o Ocaml e che il tuo sistema operativo sia Linux (o forse qualche altro OS compatibile con POSIX).
In primo luogo, potresti incorporare risorse all'interno del tuo eseguibile. Per fare ciò, si compila un grande array di byte costanti (à la XBM ), ad es. in C const char resbytes[] = { ... una sequenza molto lunga di byte, ad es. 23, 97, ecc ... }; . Questo file sorgente potrebbe ovviamente essere generato da uno script di shell (forse con l'aiuto di hexdump (1) , ecc ...)
Quindi, è possibile decidere che le risorse siano installate in un percorso fisso (o compilazione-tempo configurabile), al di fuori dell'albero di generazione. Questo è il caso della maggior parte del software GNU (come gcc , bash , emacs , make ecc ...), vedi variabili di directory dello standard di codifica GNU . Il tuo passaggio di installazione (ad esempio make install ) copi questi file in alcuni punti appropriati, ad es. sotto /usr/share/ o /usr/lib/ ecc ..... E i posti verrebbero costruiti all'interno dell'eseguibile installato (potresti averli sotto /usr/share/resources/myprog/ e passare -DRESOURCEDIR="/usr/share/resources/myprog/" al tuo g++ comando di compilazione, utilizzando i trucchi make pertinenti). Puoi trovare utile autoconf .
Si noti che sono necessarie risorse (per essere accessibili) per il file eseguibile installato, non per l'albero di compilazione.
In alternativa, almeno su Linux, potresti decidere che le risorse siano installate in un posto relativo w.r.t. il programma eseguibile (ad esempio nella directory di un nonno); IIRC è il caso di xemacs . Quindi, il problema è scoprire il percorso dell'eseguibile e della sua directory (per aggiungere successivamente un sottoprocesso relativo , come "../lib/fonts/" etc ..., ad esso). Su Linux devi solo readlink (2) il link simbolico "/proc/self/exe" (e usare dirname (3) sul risultato). Su molti altri sistemi POSIX potresti probabilmente usare il argv[0] di main e probabilmente getenv("PATH") per trovarlo e calcolarlo (forse con l'aiuto successivo di realpath (3) ...).
Alcune librerie framework (come Qt o POCO o forse GTK o i suoi Glib) potrebbero avere convenzioni su risorse e funzioni che li supportano.
Un esempio di un complesso software gratuito che richiede risorse è GCC compilatore ed esso deve essere costruito all'esterno dell'albero dei sorgenti . Potresti guardarci dentro per trarre ispirazione dalla sua "gestione delle risorse" (in particolare le intestazioni predefinite del compilatore à la <limits.h> o <stdarg.h> ...)
Per Linux, guarda anche nello Standard della gerarchia del filesystem e hier(7) che definisce le convenzioni utili.