Come gestire correttamente le dipendenze per il progetto C / C ++?

Ho un progetto che utilizza 3-4 diverse librerie C / C ++ open source.

Ho creato queste librerie per diverse piattaforme e ho fatto il check-in includendo file e librerie statiche per diverse piattaforme nel mio progetto.

Tuttavia, faccio fatica con un paio di problemi. Tutti questi progetti riguardano la gestione delle dipendenze. E sto cercando consigli sulle migliori pratiche.

1) Come faccio a sapere cosa utilizzo esattamente?

Non ho modo di ottenere una versione di una libreria statica. Di conseguenza, devo in qualche modo tenere traccia della versione di lib statica che sto usando (potrebbe essere SHA di un commit da cui è stata creata)?

Questo è particolarmente importante quando devo capire quando aggiornare queste librerie.

2) Come posso riprodurre la build?

Avrei potuto lottare per costruire una libreria specifica per una piattaforma specifica. Mi ci è voluto un po 'per capirlo.

La prossima volta che avrò bisogno di costruire la stessa biblioteca potrebbe essere tra un anno e mezzo (quando avrò bisogno di aggiornare per qualsiasi motivo. Tuttavia, a quel punto, non ricorderò assolutamente nulla e un ambiente su cui è stata costruita sarà andato via da tempo.

3) Devo fork queste librerie per avere una copia del codice sorgente?

Questa è una preoccupazione minore. Tuttavia, è ancora una preoccupazione. È bello assicurarsi che le build siano riproducibili (e quel tipo di richiede codice sorgente).

Hai davvero bisogno di usare sempre una versione esatta di una libreria dipendente? È scritto male / rompe l'API con ogni piccolo aumento della versione?

Se guardi i progetti open-source, i loro configurescript di compilazione (in gran parte) controllano la presenza di varie librerie e genera un errore in caso contrario. È anche abbastanza flessibile da consentire all'utente di collegarsi a una versione più recente della libreria (che probabilmente fornisce più correzioni di bug / sicurezza rispetto a una precedente) e non impone collegamenti statici o dinamici.

Se hai davvero bisogno di build riproducibili, dovresti anche prestare attenzione alla versione esatta del compilatore e alle sue librerie standard, forse anche al sistema operativo. In questo caso, avere una macchina di compilazione con l'ambiente esatto richiesto è, a mio avviso, meglio del check-in delle librerie compilate nel repository del codice sorgente.

Come faccio a sapere esattamente cosa utilizzo?

Se i file include o libs non contengono già un numero di versione, aggiungi un file di testo "version.txt" (contenente il numero di versione) da solo in ciascuna cartella lib e controllalo nel tuo VCS, insieme al lib e ai file include . Tuttavia, se si esegue la versione del sorgente completo della lib (punto 3), è probabile che ci sia già un file di codice sorgente contenente il numero di versione, quindi non è necessario mantenerlo proprio per questo caso.

Come riproduco la build?

Prova ad automatizzare il più possibile. Usa script, makefile o file dei tuoi strumenti di creazione preferiti. Metti tutto sotto controllo del codice sorgente. Se sono necessari passaggi manuali, annotare i dettagli in un file di testo (ad esempio, readme_build.txt) e metterlo anche nel controllo del codice sorgente.

Devo fork queste librerie per avere una copia del codice sorgente?

Dovresti avere una copia del codice sorgente , ma fork solo se necessario (ad esempio, se inciampi su un bug urgente e l'autore originale non può risolverlo entro i tuoi limiti di tempo). Oppure, se gli autori usano un ambiente di compilazione diverso da te, ed è necessario apportare alcune modifiche per far funzionare la lib nel tuo ambiente. Tuttavia, tieni presente che ogni modifica al codice sorgente originale nel tuo fork molto probabilmente rende più difficile integrare gli aggiornamenti in un secondo momento.

Tuttavia raccomando di ottenere una copia del codice sorgente originale (non gestito) delle librerie che stai usando. Ciò ti consentirà di eseguire il fork o il mantenimento della lib in un secondo momento, se necessario, anche se il manutentore originale decide di revocare le fonti lib dal web pubblico.