Makefile: Dev e Release

Question

Makefile: Dev e Release

#1 da (2 voti)

-1

In Git, ho un ramo master (release) e un ramo dev (sviluppo) per un progetto C .

Nel ramo principale, voglio gcc solo per passare il flag del compilatore -Os (ottimizzazione per la velocità) e non -ftest-coverage -fprofile-arcs (quando compilato, viene creato un file .gcno , quando eseguito, una% viene creato il file.gcda e quando viene creato gcov executable , viene creato un file .gcov .

Nel ramo di rilascio, voglio solo che il compilatore passi il flag -Os .

Posso aggiungere Makefile a .gitignore per 1 ramo, ma dovrei controllare manualmente ogni volta se Makefile è stato modificato dopo ogni push sull'altro ramo.

Posso anche non fare nulla e ricevere una notifica di una modifica in Makefile durante l'unione, ma avrei bisogno di unire manualmente il file (mantenere una riga di CFLAG+=... e scartare l'altro), ma questo è un errore- prona.

Come posso mantenere due versioni separate di Makefile su rami diversi con requisiti diversi?

Makefile

BASE=notepad

# NEEDED FOR BOTH RELEASE AND TESTING
CFLAGS=-Wall

# ONLY NEEDED IF RELEASE
CFLAGS+=-Os

# ONLY NEEDED IF TESTING COVERAGE AND PROFILING
CFLAGS+=-ftest-coverage -fprofile-arcs

all: $(BASE).exe

$(BASE).exe: $(BASE).o

$(BASE).o: $(BASE).c
    gcc $(CFLAGS) -c $(BASE).c

clean:
    rm -f $(BASE).o $(BASE).exe # ALWAYS NEEDED
    rm -f *.gcda *.gcno *.gcov  # ONLY NEEDED IF -ftest-coverage -fprofile-arcs

git c

posta gbewothcc 14.10.2018 - 18:01

fonte

1 risposta

Leggi altre domande sui tag git c

Come faccio a testare il mio pacchetto python (per la distribuzione) per diverse versioni di python? Esiste una condizione di competizione per più thread su più core che cercano di bloccare una variabile globale?

score 2 · Accepted Answer

Git non può gestire più versioni , nel senso che registra solo la cronologia dei tuoi file, non diverse varianti .

I rami non sono un meccanismo adatto per tenere traccia di diverse varianti. Non puoi avere un file che esiste solo su un ramo a meno che non elimini manualmente il file su ogni unione.

Invece, il tuo processo di compilazione dovrebbe essere in grado di produrre entrambe le varianti.

Nel tuo Makefile puoi creare diversi obiettivi per una build con copertura strumentale e una build di rilascio. Ti consigliamo di utilizzare directory di compilazione diverse in modo da non dover pulire tutti i file oggetto quando si passa da un target all'altro.

GNU Make ha molte funzioni utili, come la possibilità di eseguire il controllo delle assegnazioni delle variabili su un obiettivo specifico:
```
coverage: CFLAGS += -ftest-coverage -fprofile-arcs
release:  CFLAGS += -Os
```
Potresti anche eseguire una query su Git per scoprire il ramo corrente. Tuttavia, la build funzionerà solo se ritirata come repository Git, e non ad es. quando scompattato da un archivio zip. Questa è generalmente una soluzione comoda ma fragile, sebbene possa essere appropriata per un server CI.

(Inoltre, nota che -Os si ottimizza per la piccola dimensione , non per la velocità, sebbene i due possano essere correlati tramite effetti cache. In particolare, "-Os abilita tutte le ottimizzazioni -O2 che non in genere aumentano le dimensioni del codice. ")