Grande progetto con molte librerie esterne - organizzazione del codice sorgente

3

Mi stavo chiedendo quale sia il modo migliore per organizzare il mio codice sorgente. Stavo facendo ricerche su SO e ho trovato link ma questo layout del codice sorgente è specifico della biblioteca e non copre la mia situazione.

La mia situazione:

  • 10 moduli propri (100k righe di codice)
  • 15 librerie esterne (ad es. boost, sqlite, zlib, ecc.)
  • 2 moduli critici devono essere disponibili solo per gli sviluppatori selezionati (forse separati da repository git?)
  • Il progetto
  • è multipiattaforma (Linux e Windows)
  • Git come sistema di controllo della versione
  • cmake utilizzato per costruire il progetto

Domanda:

  • ha senso incorporare tutte le librerie nel mio progetto, ad es. nella cartella _3rd_party_libs_?
  • come gestire i percorsi include lib nei miei moduli (variabile ambientale, percorsi relativi, sottomoduli git, ecc.)?
  • dovrei sempre creare librerie esterne dal sorgente o semplicemente usare i loro binari?
posta tommyk 26.03.2013 - 13:43
fonte

1 risposta

3

does it make sense to incorporate all libraries into my project e.g. in _3rd_party_libs_ folder ?

Fai quello che vuoi, ma mantienilo coerente. Prendo atto che hai elencato esempi come boost / sqlite; questi dovrebbero essere standard nei tuoi ambienti di sviluppo e non inclusi nel tuo progetto, a meno che tu non dipenda dal dire qualche versione divertente di boost.

how to handle lib include paths in my modules (environmental variable, relative paths, git submodules, etc. ) ?

Questo è ciò che il tuo sistema di costruzione - CMake - è per. Il tuo codice sorgente ha appena #include <third_party_lib.h> senza preoccuparti di dove si trovano.

should I always build external libs from source or just used their binaries ?

Preferisci i binari di default, a meno che tu non abbia una buona ragione per costruire ogni volta da un sorgente.

    
risposta data 28.03.2013 - 13:30
fonte

Leggi altre domande sui tag