Как организовать дерево проекта для проекта C ++, используя nmake? - PullRequest
Новая
       16

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

17 голосов
/ 05 ноября 2008

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

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

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

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

Плюсы:

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

Минусы:

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

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

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

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

Плюсы:

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

Минусы:

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

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

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

  • Уменьшите уровень усилий для поддержки сценариев сборки всего решения.

  • Разделение проектов и этапы их сборки в рамках решения из других проектов.

  • Облегчите непрерывную интеграцию с помощью сценариев сборки для извлечения, чтобы выпустить генерацию медиа для каждого коммита (очевидно, используя и другие инструменты, такие как CruiseControl).

  • Сделайте добавление или удаление дополнительных проектов или исходных файлов настолько простым и наименее подверженным ошибкам, насколько это возможно для разработчиков.

Итак, я спрашиваю:

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

Ответы [ 2 ]

4 голосов
/ 06 ноября 2008

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

В «Соглашении 2: Директории проекта высокого уровня, введите подкаталоги», ваш единственный аргумент -

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

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

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

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

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

1 голос
/ 06 ноября 2008

Рассмотрите возможность использования точек соединения NTFS , чтобы вы могли иметь обе организации одновременно. Краткое определение: «точка соединения - это реализация символических ссылок Microsoft, но она работает только для каталогов».

Используйте Convention 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, отображаются в / solution / test.

...