У меня есть значительный объем исходного кода ( OOFILE ), который я наконец выставляю на Sourceforge . Мне нужно решить, следует ли мне использовать монолитный каталог include или сохранить файлы заголовков с исходным деревом.
Я хочу принять это решение перед отправкой в репозиторий svn на SourceForge. Я ожидаю, что многие люди, которые используют его после этого перемещения, сохранят рабочую копию извлеченной непосредственно из SF, поэтому не захотят менять свою структуру.
В полном дереве исходников содержится около 262 файлов в 25 папках. Есть намного больше классов, чем это предполагает, поскольку из-за соответствия именам символов 8.3 (да, это восходит к Win3.1), многие классы находятся в одном файле. Когда я разрабатывал с ObjectMaster , это меня никогда не беспокоило, но я буду разбивать его, чтобы соответствовать последним тенденциям, чтобы минимизировать количество классов в файле. Из краткого обзора списка классов существует около 600 классов.
OOFILE - это кроссплатформенный продукт, который, как ожидается, будет построен на Mac, Windows и различных Unix-платформах. Когда он начал жизнь на Mac, компиляторы, которые указывают на , включают деревья , а не на плоские , включают dirs , заголовки были сохранены вместе с источником.
Позже, в основном для того, чтобы некоторые пользователи Visual Studio были довольны, сборка была реорганизована с одним каталогом include . Я пытаюсь выбирать между этими моделями.
Весь продукт OOFILE охватывает довольно много доменов:
- интерфейс базы данных
- диапазон баз данных
- простой движок 2D-графики для Mac и Windows
- простой редактор отчетов в текстовом режиме для банального html и текстового списка
- очень богатый писатель отчетов с Mac и Windows Preview и печатью и межплатформенной генерацией текстовых, RTF, HTML и XML отчетов
- механизм интеграции форм для простой привязки форм CRUD к базе данных с реализациями на PowerPlant и MFC
- кроссплатформенные служебные классы
- манипулирование файлами и каталогами
- строка
- Массивы
- XML и генерация тегов
Многие люди хотят использовать его только на одной платформе, и некоторые из этих областей кода являются устаревшими (например, платформа PowerPlant UI на классическом Mac). Поэтому кажется, что люди были бы благодарны, если бы заголовки из этих нежелательных областей не были помещены в их монолитный каталог include.
Я начал думать о том, чтобы каталог включения был разделен на несколько доменов выше, а затем понял, что это больше похоже на исходную структуру.
В итоге, кажется, что варианты:
- Сохраняйте оригинальную модель, все заголовки примыкают к источнику - максимальная гибкость за счет некоторых компонентов, включенных в проекты.
- один включаемый каталог со всем внутри
- разделение включает в себя по доменам, поэтому для того, кто использует этот лот, может быть около 6 каталогов, но у чистого пользователя базы данных, вероятно, будет один каталог.
С точки зрения сборки Unix рекомендуемая структура была 2. Моя ситуация усложняется из-за необходимости поддерживать пользователей Visual Studio и XCode счастливыми (снифф, CodeWarrior, как я скучаю по тебе!).
Редактировать - выбранное решение:
Я пошел с четырьмя подкаталогами в include. Я начал пытаться разделить их по платформам, но очень быстро стало очень шумно.