Mam zamiar otworzyć źródło projektu C++ na Sourceforge. Czy mogę uzyskać wskazówki dotyczące organizacji kodu?

Question

Mam zamiar przesłać projekt, nad którym pracowałem na Sourceforge na licencji GPL, i miałem nadzieję uzyskać porady dotyczące sposobu organizacji kodu w sposób łatwy do zrozumienia i używania przez programistów, którzy mogą spójrz na to, co działa dobrze z git, i sposób, w jaki Sourceforge przedstawia rzeczy.

moich projektów jest cross-platform C aplikacja ++, i składa się z następujących czynności:

• część biblioteki, która ma rzeczywistej pracy
• Odrębną część GUI, który wykorzystuje część biblioteki
• Biblioteki open source, których ścieżki włączania są potrzebne do kompilacji biblioteki Zmodyfikowane biblioteki open source, które zostały zmienione, a zatem są w pewnym sensie bezpośrednią częścią tego projektu, a także
• Skompilowany wynik wszystkich bibliotek

Jaki jest najlepszy sposób na uporządkowanie?

podczas pracy nad nią sam, wraz z cebulkami projektu mam to tak:
/LibPortion
/GuiPortion
/libs/bibliotek open source
biblioteki /libs/zmodyfikowane open source
/libs/skompilowany/do przechowywania skompilowanych bibliotek, w tym podczas kompilowania dla systemu Windows niektórych, które nie pochodzą z bibliotek open source, takich jak pliki biblioteki Cygwin.

Czy jest to rozsądny sposób organizowania rzeczy? Czy to pasuje do konwencji i oczekiwań?

Czy podczas sprawdzania w moim projekcie warto sprawdzić biblioteki Open Source, a także część projektu? Sądzę, że ma to sens, ponieważ minimalizuje to tarcia w związku z przygotowaniem i uruchomieniem projektu dla nowego dewelopera. Na pewno powinienem przynajmniej sprawdzić zmodyfikowane biblioteki open source.

Co jest sensownego dołączania do repozytorium w skompilowanych bibliotekach? Myślę, że najlepiej byłoby powiedzieć git, aby zignorował ten katalog i pozostawił go pustym, ponieważ jego zawartość będzie inna w każdym celu kompilacji, ponieważ mój projekt jest wieloplatformowy.

Jednak dla osób, które nie chcą mieć kłopotów z budowaniem i/lub pobieraniem wszystkich bibliotek, wydaje się naprawdę dobre dla bibliotek wstępnie skompilowanych dla głównych platform. Jaki jest najmądrzejszy sposób, żeby się nimi podzielić? Patrzę na Sourceforge i nie jest dla mnie oczywiste, jak powinienem się nimi podzielić, jeśli nie jako częścią mojego repozytorium git.

Answer 1

Generalnie oddziel swoją pracę od pracy osób trzecich. Na najbardziej podstawowym poziomie, folder główny może wyglądać tak:

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

ja oddzielone folder „osób trzecich” na dwa podfoldery dla celów zgodności licencyjnej i łatwości użytkowania. To, w jaki dokładnie sposób dystrybuujesz biblioteki stron trzecich, zależy wyłącznie od ich licencji. Skonfiguruj pliki Makefile tak, aby skompilowane biblioteki wylądowały w folderze third-party\lib (tam też możesz umieścić wszystkie wstępnie skompilowane biblioteki). W ten sposób użytkownik może pobrać wstępnie skompilowane biblioteki i zignorować folder source lub pobrać kod źródłowy i zignorować folder lib w zależności od tego, czy chce on ponownie zbudować bibliotekę firm trzecich.

Jeśli wymagane jest rozpowszechnienie zmodyfikowanej wersji w postaci kodu binarnego i kodu źródłowego, to musisz zmodyfikować wersję w repozytorium źródłowym (pod warunkiem, że wybrana jest wstępnie skompilowana biblioteka).

Jeśli używasz niezmodyfikowanej biblioteki i korzystasz z repozytorium Subversion (lub podobnego), możesz użyć właściwości externals, aby połączyć swoje repozytorium z repozytorium biblioteki strony trzeciej, tak że gdy użytkownik otrzyma kopię Twojego źródła kod, pobiera źródło biblioteki z własnego repozytorium. W ten sposób nie musisz przechowywać lokalnego zwierciadła źródła biblioteki. W zależności od tego, jakie biblioteki stron trzecich są dostępne w repozytorium, możesz również użyć zewnętrznych do połączenia ze skompilowaną wersją lib innej firmy. To nie tylko zmniejszy ilość kodu, który będziesz musiał obsługiwać w swoim repozytorium, ale będzie również wyraźniej wskazywać, że dana lib innej firmy nie została zmodyfikowana.

Korzystając z niezmodyfikowanych bibliotek, lepiej nie dołączać źródła lub pliku binarnego do drzewa źródłowego. Po prostu zanotuj w swojej dokumentacji, że twój projekt zależy od biblioteki X (podaj także wersję, jeśli jest ważna) i podaj link do strony głównej projektu tej biblioteki/strony/repozytorium Sourceforge. Pozwól programistom zdecydować, czy chcą skompilować bibliotekę, pobrać wstępnie skompilowaną wersję lub ewentualnie użyć wersji, którą już zainstalowali. Oznacza to, że nie można również założyć, że biblioteka lub jej nagłówki będą istnieć w określonym katalogu względem kodu źródłowego; zamiast tego będziesz musiał ufać użytkownikowi, aby zainstalować biblioteki, w których może je znaleźć kompilator. Twój kod będzie po prostu zakładał, że znajdują się w ścieżce wyszukiwania kompilatora.

Możliwe jest również, że zmodyfikowane biblioteki są zaimplementowane w taki sposób, że właściwość externals spowoduje pobranie niezmodyfikowanego źródła z repozytorium zewnętrznego, a system kompilacji może zastosować poprawkę zawierającą modyfikacje. W ten sposób technicznie nie rozpowszechniałbyś zmodyfikowanego kodu, co może oznaczać kilka warunków licencji, których musisz przestrzegać.

Zazwyczaj nie polecam dystrybuowania wstępnie skompilowanych wersji biblioteki wewnątrz repozytorium źródłowego. Dzięki Sourceforge możesz wstępnie skompilować swoją bibliotekę (lub dowolny inny "produkt końcowy") dla głównych platform i zaoferować ją jako pliki do pobrania.

Answer 2

Gdybym był tobą, najpierw rozdzieliłbym projekt pomiędzy twój własny kod i biblioteki stron trzecich. Poniższy drzewo może pracować:

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

Nie ma być hostem skompilowane biblioteki na swoim repozytorium IMHO. Bardziej elastyczne jest pozwalanie programistom na kompilowanie ich na własnym komputerze, ale jeśli chcesz mieć dostępne archiwum, powinno ono zawierać skompilowane biblioteki.

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. 

Jest to organizacja, z której korzystam ostatnio i która została bardzo doceniona przez wszystkich uwzględnionych. Ułatwia także oddzielanie bibliotek między sobą i ułatwia udostępnianie w bibliotekach wewnętrznych nagłówków i zewnętrznych nagłówków.

Edytuj: Dodano "lokalny" reż.

Answer 4

IMHO patrząc na organizację różnych projektów open source może pomóc.

vlc project page może być dobre referencje