Структура каталогов для библиотеки C++

Question

Я работаю над библиотекой C++. В конечном счете, я хотел бы сделать его общедоступным для нескольких платформ (по крайней мере, Linux и Windows), а также некоторые примеры и привязки Python. Работа идет хорошо, но на данный момент проект довольно грязный, построенный исключительно для Visual C++, а не для нескольких платформ.

Поэтому я чувствую, что очистка в порядке. Первое, что я хотел бы улучшить, это структура каталога проекта. Я хотел бы создать структуру, которая подходит для инструментов Automake, чтобы упростить компиляцию на нескольких платформах, но я никогда не использовал их раньше. Так как я все еще буду делать (большую часть) кодирование в Visual Studio, мне нужно где-то сохранить мои проекты и файлы Visual Studio.

Я пытался использовать Google для терминов, таких как «структура каталогов библиотек на C++», но ничего полезного, похоже, не возникает. Я нашел некоторые основные рекомендации, но не имел четких решений.

При просмотре некоторых библиотек с открытым исходным кодом, я придумал следующее:

\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 
    ... 

У меня нет/мало предыдущий опыт разработки мультиплатформенной/проектов с открытым исходным кодом, и я очень удивлен, что я не могу найти любые хорошие рекомендации о том, как структурировать такой проект.

Как следует структурировать такой проект библиотеки? Что рекомендуется читать? Есть ли хорошие примеры?

Answer 1

Одна вещь, которая очень распространена среди библиотек Unix является то, что они организованы таким образом, что:

./   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` 

Это несколько отражает традиционный Unix файловой системы под /usr где:

/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. 

Конечно, это может закончите в /usr/local (который является префиксом установки по умолчанию для GNU autoconf), и они могут вообще не придерживаться этой структуры.

Нет жесткого правила. Я лично так не организовываю подобные вещи. (Я не использовать каталог ./src/ на всех для самых крупных проектов, за исключением, например, я не использую Autotools, предпочитая вместо этого CMake.)

Мое предложение к вам, что вы должны выбрать макет каталога, марки смысл для вас (и ваша команда). Сделайте то, что наиболее разумно для выбранной вами среды разработки, создания инструментов и управления версиями.

Answer 2

Я не думаю, что на самом деле есть хорошие рекомендации для этого. Большинство из них - только личное предпочтение. Однако определенные IDE будут определять базовую структуру для вас. Visual Studio, например, создаст отдельную папку bin, которая будет разделена на подпапки Debug и Release. В VS это имеет смысл, когда вы компилируете свой код с использованием разных целей. (Режим отладки, Режим деблокирования.)

Как говорит greyfade, используйте макет, который имеет смысл для вас. Если кому-то это не нравится, им просто нужно будет его перестроить. К счастью, большинство пользователей будут довольны выбранной вами структурой. (Если это не бесполезно.)

Answer 3

Я считаю, что библиотека wxWidgets (с открытым исходным кодом) является хорошим примером. Они поддерживают множество различных платформ (Win32, Mac OS X, Linux, FreeBSD, Solaris, WinCE ...) и компиляторы (MSVC, GCC, CodeWarrior, Watcom и т. д.). Вы можете увидеть макет дерева здесь:

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