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

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

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

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

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

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

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

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

Ответ 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.)

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

Ответ 2

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

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

Ответ 3

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

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