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

Я пропоную вам, щоб ви вибрали макет каталогу, який має сенс для вас (і вашої команди). Робіть все, що є найбільш розумним для вибраного вами середовища розробки, створюйте інструменти та контроль джерел.

Існує така дивовижна конвенція, з якою я нещодавно зіткнувся, яка може бути корисною: Макет Pitchfork (також на GitHub ).

Підводячи підсумок, у підрозділі 1.3 зазначено, що:

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

Інші каталоги не повинні відображатися в корені.

build/: Спеціальний каталог, який не слід вважати частиною джерела проекту. Використовується для зберігання ефемерних результатів побудови. не слід перевіряти в контролі джерела. Якщо використовується керування джерелом, його слід ігнорувати за допомогою списків ігнорування керування джерелом.

src/: Основне розташування джерела, що складається. Повинен бути присутнім для проектів зі скомпільованими компонентами, які не використовують підмодулі. У присутностіinclude/ , також містить приватні заголовки.

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

tests/: Довідник для тестів.

examples/: Довідник зразків та прикладів.

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

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

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

tools/: Каталог, що містить утиліти розробки, такі як сценарії побудови та рефакторингу

docs/: Каталог проектної документації.

libs/: Каталог основних підмодулів проекту.

Крім того, я думаю, що extras/каталог - це те, куди повинні йти ваші прив’язки Python .

Я не думаю, що насправді для цього існує якісь якісь настанови. Більшість із них - лише особисті переваги. Однак деякі IDE визначають базову структуру для вас. Наприклад, Visual Studio створить окрему папку bin, яка розділена на підпапки Debug and 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, і ви зможете писати крос-платформний код із власною структурою директорій у всіх системах.