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

Я работаю над библиотекой 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
    ...

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

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

Одна вещь, которая очень распространена среди библиотек 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/вообще избегаю использования каталога, за исключением, например, самых крупных проектов. Я также не использую автоинструменты, предпочитая вместо этого CMake.)

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

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

Подводя итог, в подразделе 1.3 говорится, что:

PFL предписывает несколько каталогов, которые должны находиться в корне дерева проекта. Не все каталоги требуются, но у них есть назначенная цель, и никакой другой каталог в файловой системе не может брать на себя роль одного из этих каталогов. То есть эти каталоги должны быть теми, которые используются, если требуется их назначение.

Другие каталоги не должны появляться в корне.

build/: Специальный каталог, который не следует рассматривать как часть исходного кода проекта. Используется для хранения эфемерных результатов сборки. не должны проверяться в системе контроля версий. При использовании системы контроля версий следует игнорировать использование списков игнорирования системы контроля версий.

src/: Расположение основного компилируемого источника. Должен присутствовать для проектов с скомпилированными компонентами, которые не используют подмодули. При наличии include/также содержит закрытые заголовки.

include/: Каталог общедоступных заголовков. Может присутствовать. Может быть опущено для проектов, которые не различают частные и публичные заголовки. Может быть опущено для проектов, в которых используются подмодули.

tests/: Справочник для тестов.

examples/: Справочник образцов и примеров.

external/: Каталог для пакетов / проектов, которые будут использоваться в проекте, но не будут редактироваться как часть проекта.

extras/: Каталог, содержащий дополнительные / необязательные подмодули для проекта.

data/: Каталог, содержащий аспекты проекта, не связанные с исходным кодом. Сюда могут входить файлы графики и разметки.

tools/: Каталог, содержащий служебные программы разработки, такие как сценарии сборки и рефакторинга.

docs/: Справочник проектной документации.

libs/: Справочник основных подмодулей проекта.

Кроме того, я думаю, что extras/каталог - это то место, куда должны идти ваши привязки Python .

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

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

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

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

Я действительно могу порекомендовать вам использовать CMake ... это для кроссплатформенной разработки, и он намного более гибкий, чем automake, используйте CMake, и вы сможете писать кросс-платформенный код со своей собственной структурой каталогов во всех системах.