Come evitare problemi di concorrenza quando si utilizza GNU make per build paralleli di file di archivio?

Question

Sto usando GNU make per creare un gruppo di librerie statiche, usando le regole implicite del make per farlo. Queste regole eseguono il comando ar (1) per aggiornare la libreria/archivio. Il profiling ha mostrato che il tempo di compilazione sarebbe stato ridotto se avessi usato l'opzione -j per eseguire i lavori paralleli durante la compilazione.

Purtroppo, la GNU fare manuale ha una sezione http://www.gnu.org/software/make/manual/html_node/Archive-Pitfalls.html che praticamente dice che make fornisce guardie di concorrenza per l'esecuzione di ar (1), e quindi si può (e lo fa) corrotto l'archivio. Il manuale anticipa ulteriormente che ciò potrebbe essere risolto in futuro.

Una soluzione a questo è utilizzare http://code.google.com/p/ipcmd, che in pratica fa bloccare il semaforo prima di eseguire un comando, serializzando in questo modo i comandi ar (1) che creano l'archivio. Questa particolare soluzione non mi va bene perché sto costruendo con strumenti cross-compilation basati su mingw su Windows.

C'è una soluzione più semplice o migliore a questo problema?

Answer 1

Fare l'archiviazione come un singolo passo, piuttosto che cercare di aggiornare l'archivio in modo incrementale:

libfoo.a: $(OBJS) 
     -rm -f $@ 
     $(AR) rc $@ $^ 
     $(RANLIB) $@ 

Answer 2

Provate il seguente -

AR := flock make.lock $(AR) 

clean:: 
    rm -f make.lock 

Ora ar (1) eseguirà con un blocco esclusivo al file make.lock, quindi serializzando l'accesso alla libreria.

È possibile aggiungere un comando per eliminare il file make.lock dopo il comando ranlib.

Aggiungere export AR per propagare la definizione a sub-marche, se necessario.