Структура каталогов для библиотеки 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
    ...

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

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

62
automake c++ directory-structure

3 ответов

одна вещь, которая очень распространена среди библиотек 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.)

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

84

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

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

5

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

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

4