Make: ricerca avida di fonti contro un approccio più selettivo ... o un ibrido?

Question

Make: ricerca avida di fonti contro un approccio più selettivo ... o un ibrido?

#1 da (2 voti)
#2 da (0 voti)

0

Ho riscritto il mio makefile qualche tempo fa per ottenere il vantaggio di cercare e compilare avidamente tutte le fonti in una cartella radice. Sono molto soddisfatto, tranne per il fatto che le librerie di sorgenti che includo come sottomoduli tendono ad avere un sacco di file spazzatura, ad es. esempi, test o altre fonti di cui non ho bisogno ... e il processo decisionale li soffoca. Questo è il posto in cui sono attualmente.

Quindi sono tornato indietro per capire perché può essere meglio elencare esplicitamente le fonti. Il problema è che bisogna sempre ricordare di modificare il Makefile ogni volta che nuove sorgenti vengono aggiunte all'albero. Questo è noioso, e la ragione per cui sono andato inizialmente con quanto sopra.

Ora comincio a chiedermi se non esiste un metodo per consentire un mix dei due. Ad esempio, cosa succede se alcune cartelle avevano un manifest in esse che specificava determinati file da compilare, mentre altre cartelle senza un manifest causavano il makefile di default per "compilare tutto qui"?

Sono un po 'giovane, quindi sembra saggio o imprudente? Consigli su come configurarlo? Le insidie?

P.S. Ho preso in considerazione il controllo spoglio dei sottomoduli per risolvere la questione senza modificare il mio makefile corrente, ma SourceTree non lo supporta ancora, e mi baso molto su di esso per il mio uso di git.

c make gnu

posta Engineer 26.09.2015 - 21:07

fonte

2 risposte

Leggi altre domande sui tag c make gnu

In che modo l'algoritmo di Luhn si riferisce alle funzioni hash crittografiche? legge il file bytewise e trova le informazioni

score 2 · Answer 1

Stai chiedendo una soluzione tecnologica per un problema non tecnologico.

Hai questi vincoli:

Tutti i file con determinate estensioni sotto una directory sono file del codice sorgente che fanno parte del progetto.
Tranne che le persone creano a caso file aggiuntivi che violano il primo vincolo.
Tranne che alcuni file casuali aggiuntivi non violano il primo vincolo.

Le tue opzioni includono:

Insegna alle persone di utilizzare una convenzione di denominazione per i file temporanei.
Ignora il file system e compila il sistema di controllo del codice sorgente.
Compila solo ciò che è stato compilato l'ultima volta e chiedi informazioni sui nuovi file.
Crea molte combinazioni diverse di compilation e mantieni solo quelle che compilano.
Scopri come compilare abbastanza velocemente da non avere importanza. (La lingua Go ha questo come vincolo di progettazione.)

Non c'è davvero alcun modo per avere completamente la tua torta e mangiare completamente è pure.

score 0 · Answer 2

Una soluzione ibrida era davvero il risultato finale.

Il mio makefile ora contiene due variabili separate:

una lista di directory che possono essere cercate sia in modo esaustivo E ricorsivamente per le fonti da compilare - questo è usato per il codice principale dell'applicazione su cui ho il controllo e che cambia anche molto spesso, quindi non ho bisogno di aggiungere / rimuovere esplicitamente fonti / dal makefile ogni volta che aggiungo / rimuovo / dalla struttura dei sorgenti dell'applicazione;
una lista di fonti esplicite, selezionate con cura - usate per le librerie su cui non ho controllo e dove devo quindi scegliere le singole fonti per evitare la compilazione di fonti indesiderate come test ed esempi.

... Combinando questi due elementi in un'unica lista, ora ho il mio elenco completo per passare a $ CC, con un controllo maggiore e solo marginalmente meno comodità.