Как организовать дерево проекта для проекта С++ с использованием nmake?

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

Конвенция 1: Каталоги высокого уровня, суб-каталоги проектов

Например, проект wxWidgets использует этот стиль:

/solution
   /bin
      /prj1
      /prj2
   /include
      /prj1
      /prj2
   /lib
      /prj1
      /prj2
   /src
      /prj1
      /prj2
   /test
      /prj1
      /prj2

Плюсы:

Если существуют зависимости проекта, их можно управлять из одного файла
Структура плоской сборки

Минусы:

Поскольку у теста есть свои собственные файлы заголовков и cpp, при создании unit test приложений для EXE файлов, а не библиотек, они должны включать объект файлов из тестируемого приложения. Это требует от вас создания правил вывода и расширения относительных путей для всех исходных файлов.
Повторное использование любого из проектов в другом решении требует, чтобы вы извлекали правильные файлы из древовидной структуры и изменяли любые скрипты сборки

Конвенция 2: Каталог проектов высокого уровня, подкаталоги типов

Например, проект Wireshark использует этот стиль

/solution
   /prj1
      /bin
      /include
      /lib
      /src
      /test
   /prj2
      /bin
      /include
      /lib
      /src
      /test

Плюсы:

Проекты сами по себе автономны в своих папках, что облегчает их перемещение и повторное использование.
Позволяет использовать более короткие правила вывода в инструментах построения.
Облегчает скрипты иерархической сборки

Минусы:

Если существуют зависимости между проектами, вам нужен дополнительный уровень скриптов сборки над каталогами проектов для управления порядком сборки

В настоящее время мы используем соглашение 1 по нашему проекту, и до сих пор он работал достаточно хорошо. Теперь я в процессе добавления модульного тестирования (через CxxTest) и облегчения перехода к непрерывной интеграции с помощью nmake, соглашение 1 вызывает некоторые серьезные головные боли при создании соответствующих файлов nmake.

Мои основные требования/цели:

Уменьшите уровень усилий для поддержки скриптов сборки всего решения.
Де-пара проектов и их шаги сборки в рамках решения других проектов.
Облегчайте непрерывную интеграцию с помощью скриптов сборки для регистрации, чтобы освободить создание мультимедиа для каждой фиксации (очевидно, используя другие инструменты, такие как CruiseControl).
Сделать добавление или удаление дополнительных проектов или исходных файлов максимально простым и максимально подверженным ошибкам для разработчиков.

Поэтому я спрашиваю:

Есть ли другие плюсы и минусы любой из этих методов?
Есть ли четкий способ, который способствует только одному из этих конвенций?

Ответ 1

[Частичный ответ.]

В разделе "Конвенция 2: проектные проекты высокого уровня, введите подкаталоги", ваш единственный символ

Если существуют зависимости между проектов, вам нужен дополнительный слой сценариев сборки над проектом каталоги для управления порядком сборки

Это также можно рассматривать как профессионал во многих проектах.

Если у вас много повторяющихся общих определений, вероятно, вам понадобится файл include для скриптов сборки, где могут быть определены константы и параметры решения. Таким образом, "дополнительный уровень скриптов сборки" часто будет иметь место, даже если нет (прямых) зависимостей.

Это профессионал в том, что в здании еще есть место для более модульного подхода. С другой стороны, если вы хотите повторно использовать проект в другом, несвязаном решении, вам нужно будет составить другой файл определений. (С другой стороны, если для всего решения был создан один файл сборки, как в Конвенции 1, вам понадобится другая сборка script.) Что касается вашего требования к техническому обслуживанию, то (IMO) очень зависит от проекта.

Мое чувство склоняется к Конвенции 2, но это далеко не однозначная победа. Фактически, ваш опыт работы с Конвенцией 1, который хорошо работал до недавнего времени, может быть самым большим за всех: команда людей с опытом работы с определенной организацией является ценным активом.

Ответ 2

Рассмотрите возможность использования точек соединения NTFS, чтобы вы могли одновременно иметь обе организации. Быстрое определение: "точкой соединения является реализация символических ссылок Microsoft, но она работает только для каталогов".

Используйте "Конвенцию 2" для "реальной" компоновки, поскольку она упрощает перемещение проектов. Затем создайте представление Конвенции 1:

mkdir /solution/test
linkd /solution/test/prj1 /solution/prj1/test
linkd /solution/test/prj2 /solution/prj2/test

Теперь у вас есть...

/solution
  /test
    /prj1
    /prj2

..., что было желательным результатом.

Вы можете сделать то же самое для /src или других каталогов, если найдете это полезным. Тестовые сценарии, которые извлекают выгоду из Конвенции 1, отображают live in/solution/test.