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