Struktura katalogów dla biblioteki C ++

Pracuję nad biblioteką C ++. Ostatecznie chciałbym udostępnić go publicznie na wiele platform (przynajmniej Linux i Windows), wraz z kilkoma przykładami i powiązaniami Pythona . Prace przebiegają nieźle, ale w tej chwili projekt jest dość chaotyczny, zbudowany wyłącznie w i dla Visual C ++, a nie w ogóle wieloplatformowy.

Dlatego uważam, że porządek jest w porządku. Pierwszą rzeczą, którą chciałbym poprawić, jest struktura katalogów projektu. Chciałbym stworzyć strukturę odpowiednią dla narzędzi Automake , aby umożliwić łatwą kompilację na wielu platformach, ale nigdy wcześniej ich nie używałem. Ponieważ nadal będę wykonywał (większość) kodowania w programie Visual Studio, będę potrzebować miejsca, w którym będę przechowywać również pliki projektów i rozwiązań programu Visual Studio.

Próbowałem znaleźć w Google terminy takie jak „Struktura katalogów biblioteki C ++”, ale nie pojawiają się żadne przydatne informacje. Znalazłem kilka bardzo podstawowych wskazówek, ale nie ma krystalicznie jasnych rozwiązań.

Przeglądając niektóre biblioteki open source, wymyśliłem następujące rzeczy:

\mylib
    \mylib <source files, read somewhere to avoid 'src' directory>
        \include? or just mix .cpp and .h
    \bin <compiled examples, where to put the sources?>
    \python <Python bindings stuff>
    \lib <compiled library>
    \projects <VC++ project files, .sln goes in project root?>
    \include? 
    README
    AUTHORS
    ...

Nie mam wcześniejszego doświadczenia z programowaniem wieloplatformowym / projektami open source / mam małe doświadczenie i jestem bardzo zdumiony, że nie mogę znaleźć dobrych wskazówek, jak zorganizować taki projekt.

Jak ogólnie należy zorganizować taki projekt biblioteczny? Co warto przeczytać? Czy są jakieś dobre przykłady?

Jedną z rzeczy, która jest bardzo powszechna wśród bibliotek uniksowych, jest to, że są zorganizowane w taki sposób, że:

./         Makefile and configure scripts.
./src      General sources
./include  Header files that expose the public interface and are to be installed
./lib      Library build directory
./bin      Tools build directory
./tools    Tools sources
./test     Test suites that should be run during a `make test`

W pewnym stopniu odzwierciedla tradycyjny system plików Uniksa, w /usrktórym:

/usr/src      Sometimes contains sources for installed programs
/usr/include  Default include directory
/usr/lib      Standard library install path
/usr/share/projectname   Contains files specific to the project.

Oczywiście mogą one skończyć się w /usr/local(co jest domyślnym prefiksem instalacyjnym dla GNU autoconf) i mogą w ogóle nie przylegać do tej struktury.

Nie ma sztywnej reguły. Osobiście nie organizuję rzeczy w ten sposób. (W ./src/ogóle unikam używania katalogu, z wyjątkiem na przykład największych projektów. Nie używam też autotools, wolę CMake.)

Moja sugestia jest taka, że ​​powinieneś wybrać układ katalogu, który będzie odpowiedni dla Ciebie (i Twojego zespołu). Zrób wszystko, co jest najbardziej rozsądne dla wybranego środowiska programistycznego, narzędzi do tworzenia i kontroli źródła.

Jest taka niesamowita konwencja, z którą niedawno się spotkałem, która może być pomocna: The Pitchfork Layout (również na GitHub ).

Podsumowując, w podrozdziale 1.3 stwierdza się, że:

PFL określa kilka katalogów, które powinny pojawić się w katalogu głównym drzewa projektu. Nie wszystkie katalogi są wymagane, ale mają przypisane przeznaczenie i żaden inny katalog w systemie plików nie może pełnić roli jednego z tych katalogów. Oznacza to, że te katalogi muszą być tymi, które są używane, jeśli ich cel jest wymagany.

Inne katalogi nie powinny pojawiać się w katalogu głównym.

build/: Specjalny katalog, który nie powinien być uważany za część źródła projektu. Służy do przechowywania efemerycznych wyników kompilacji. nie mogą być wpisane do kontroli źródła. Jeśli używasz kontroli źródła, należy je zignorować za pomocą listy ignorowanych-list kontroli źródła.

src/: Główna kompilowalna lokalizacja źródła. Musi być obecny w przypadku projektów ze skompilowanymi komponentami, które nie używają modułów podrzędnych. W obecności include/zawiera również prywatne nagłówki.

include/: Katalog publicznych nagłówków. Może być obecny. Można pominąć w przypadku projektów, w których nie ma rozróżnienia między nagłówkami prywatnymi i publicznymi. Można pominąć w przypadku projektów korzystających z modułów podrzędnych.

tests/: Katalog testów.

examples/: Katalog próbek i przykładów.

external/: Katalog pakietów / projektów, które mają być używane przez projekt, ale nie są edytowane jako część projektu.

extras/: Katalog zawierający dodatkowe / opcjonalne moduły podrzędne dla projektu.

data/: Katalog zawierający aspekty projektu niebędące kodem źródłowym. Może to obejmować pliki graficzne i znaczniki.

tools/: Katalog zawierający narzędzia programistyczne, takie jak skrypty kompilacji i refaktoryzacji

docs/: Katalog dokumentacji projektowej.

libs/: Katalog dla głównych modułów podrzędnych projektu.

Ponadto myślę, że extras/katalog jest miejscem, w którym powinny znajdować się wiązania Pythona .

Myślę, że nie ma dobrych wskazówek na to. Większość z nich to tylko osobiste preferencje. Jednak niektóre IDE określą dla Ciebie podstawową strukturę. Na przykład program Visual Studio utworzy oddzielny folder bin, który jest podzielony na podfoldery Debug i Release. W VS ma to sens, gdy kompilujesz kod przy użyciu różnych celów. (Tryb debugowania, tryb wydania).

Jak mówi greyfade, użyj układu, który ma dla ciebie sens. Jeśli komuś się to nie spodoba, będzie musiał po prostu samodzielnie go zrestrukturyzować. Na szczęście większość użytkowników będzie zadowolona z wybranej struktury. (Chyba że jest naprawdę niechlujny.)

Uważam, że biblioteka wxWidgets (open source) jest dobrym przykładem. Obsługują wiele różnych platform (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...) i kompilatory (MSVC, GCC, CodeWarrior, Watcom itp.). Możesz zobaczyć układ drzewa tutaj:

https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/

Mogę naprawdę polecić używanie CMake ... jest to programowanie międzyplatformowe i jest znacznie bardziej elastyczne niż automake, używanie CMake i będziesz mógł pisać kod międzyplatformowy z własną strukturą katalogów na wszystkich systemach.