Sto per aprire un progetto C++ su Sourceforge. Posso avere qualche consiglio sull'organizzazione del codice?

Question

Sto per caricare un progetto su Sourceforge sotto GPL e speravo di avere qualche consiglio su come organizzare il codice in modo facile da capire e da usare da parte di qualsiasi sviluppatore che potesse guardalo, che funziona bene con git, e il modo in cui Sourceforge presenta le cose.

miei progetti è un'applicazione multi-piattaforma C++, e si compone dei seguenti:

• Una parte della libreria, che fa il lavoro effettivo
• Una parte GUI separato, che utilizza la parte libreria
• Librerie open source, i cui percorsi include sono necessari per compilare la libreria
• Librerie open source modificate, che sono state modificate e quindi sono in qualche modo una parte diretta di questo progetto pure
• Output compilato di tutte le librerie

Qual è il modo migliore per organizzare questo?

Mentre si lavora su di esso me stesso, dalla radice progetto che ho in questo modo:
/LibPortion
/GuiPortion
/libs/librerie open source
librerie /libs/modificato open source
/libs/compilato/per contenere le librerie compilate, incluso durante la compilazione per Windows alcuni che non provengono dalle librerie open source, come i file della libreria Cygwin

È un modo ragionevole di organizzare le cose? Corrisponde a convenzioni e aspettative?

Durante il controllo del mio progetto, ha senso controllare le librerie open source e parte del progetto? Immagino che abbia senso farlo, perché riduce al minimo l'attrito con il progetto e il funzionamento di un nuovo sviluppo. Certamente dovrei almeno controllare le librerie open source modificate.

Inoltre, cosa ha senso includere nel repository sotto librerie compilate? Sto pensando che sarebbe meglio dire a git di ignorare quella directory e lasciarla vuota, dal momento che il suo contenuto sarà diverso su ogni target di costruzione, dal momento che il mio progetto è multipiattaforma.

Tuttavia, sembra anche molto bello per le persone che non vogliono complicare la costruzione e/o il download di tutte le librerie stesse per offrire le librerie precompilate per le principali piattaforme. Qual è il modo più intelligente per condividerli? Sto guardando Sourceforge, e non mi è subito chiaro come dovrei condividerli se non come parte del mio repository git.

Answer 1

In generale, separare il lavoro da quello di terze parti. Al livello più elementare, la cartella principale potrebbe essere simile:

|- GUI 
|- Library 
|- Third-party 
    |- lib 
    |- source 

ho separato la cartella "di terze parti" in due sottocartelle ai fini della conformità delle licenze e facilità d'uso. Quanto esattamente distribuisci le librerie di terze parti dipenderà interamente dalle loro licenze. Configura i tuoi makefile in modo che le librerie compilate finiscano nella cartella third-party\lib (che è anche la posizione in cui posizionerai le librerie precompilate). In questo modo l'utente può scaricare le librerie precompilate e ignorare la cartella source o scaricare il codice sorgente e ignorare la cartella lib a seconda che vogliano o meno ricostruire le librerie di terze parti.

Se si sono tenuti a distribuire la propria versione in forma di codice binario e la fonte, allora si avrà bisogno di ospitare il vostro versione modificata nel repository di origine (fornendo un lib precompilato è la vostra scelta).

Se si utilizza una libreria non modificata e si utilizza un repository Subversion (o simile), è possibile utilizzare la proprietà externals per collegare il repository al repository della libreria di terze parti in modo tale che quando un utente riceve una copia dell'origine codice, afferra la fonte della lib dal proprio repository. In questo modo, non è necessario mantenere un mirror locale dell'origine della libreria. A seconda di ciò che la libreria di terze parti è disponibile nel suo repository, potresti essere in grado di utilizzare anche gli esterni per collegarti a una versione precompilata della lib di terze parti. Questo non solo ridurrà la quantità di codice che dovrete ospitare nel repository, ma indicherà anche più chiaramente che la particolare libreria di terze parti non è stata modificata.

Quando si utilizzano librerie non modificate, sarebbe ancora meglio non includere affatto l'origine o il binario nell'albero sorgente. Basta prendere nota nella documentazione che il progetto dipende dalla libreria X (specificare anche la versione, se è importante) e fornire un collegamento alla homepage del progetto di quella libreria/pagina Sourceforge/repository. Lascia che lo sviluppatore decida se vuole compilare la libreria, scaricare una versione precompilata o eventualmente utilizzare la versione che ha già installato. Ciò significa che non puoi nemmeno presumere che la libreria o le sue intestazioni esisteranno in una particolare directory relativa al tuo codice sorgente; invece, dovrai fidarti dell'utente per installare le librerie in cui il compilatore può trovarle. Il tuo codice assumerà semplicemente che si trovano nel percorso di ricerca del compilatore.

È anche possibile che le librerie modificate siano implementate in modo tale che una proprietà esterna causi il recupero dell'origine non modificata dal repository di terze parti e che il sistema di generazione possa applicare una patch contenente le modifiche. In questo modo, tecnicamente non distribuirai codice modificato, il che potrebbe significare molti meno termini di licenza a cui devi conformarti.

In genere, non è consigliabile distribuire versioni precompilate della libreria nel repository di origine. Con Sourceforge, puoi precompilare la tua libreria (o qualsiasi altro "prodotto finale") per le principali piattaforme e offrirle come download.

Answer 2

Se fossi in te, prima separerei il progetto tra il tuo codice personale e le librerie di terze parti. Il seguente albero potrebbe funzionare:

/ 
|- GUI 
|- lib 
|- third parties 
    |- compiled targets 
    |- "your first library" 
    |- "another library" 
    |- ... 

Non si dovrebbe ospitare le librerie compilato sul imho repository. È più flessibile consentire agli sviluppatori di compilarli sul proprio computer, ma se si desidera avere un archivio tar distribuibile, dovrebbe includere librerie precompilate.

Answer 3

/
|- bin - Compiled binaries go here (not submitted to source-control) 
|- build - buildscripts, tools used to build your code. 
|- lib - Compiled libraries go here (not submitted to source-control) 
|- local - (not submitted to source control) 
    |- obj - Compiled object-files (not submitted to source-control) 
    |- msvc - Autogenerated solution files for visual studio (not submitted to source control) (if applicable) 
    |- scripts - Autogenerated script files (if applicable) 
|- units 
    |- libportion 
     |- include - external headers for other units to see 
     |- src 
    |- guiportion 
     |- include 
     |- src 
|- external 
    |- externallib1 
     |- include 
     |- src 

build - simplified build-script calling the correct convention to your buildscripts. 
README - text-file explaining your software and the layout of your source. 

Questa è l'organizzazione che ho utilizzato recentemente ed è stata molto apprezzata da tutti. Inoltre, semplifica la separazione delle librerie tra di loro e facilita la fornitura di intestazioni interne e intestazioni esterne nelle librerie.

Modifica: aggiunta la dir "locale".

Answer 4

IMHO potrebbe essere di aiuto nell'organizzazione di vari progetti open source.

vlc project page può essere un buon riferimento