Использование Makefile вместо файлов решения/проекта в Visual Studio (2005)

Question

Есть ли у кого-нибудь опыт использования make-файлов для сборок Visual Studio C++ (под VS 2005), а не использования настройки проекта/решения.Для нас способ работы проекта/решений не является интуитивным и приводит к взрыву конфигурации, когда вы пытаетесь настроить сборки с определенными флагами времени компиляции.

В Unix довольно легко настроить make-файл, параметры которого по умолчанию переопределяются пользовательскими настройками (или другими параметрами конфигурации).Но выполнение подобных задач в Visual Studio кажется трудным.

Например, у нас есть проект, который необходимо собрать для трех разных платформ.Каждая платформа может иметь несколько конфигураций (например, отладочная, релизная и некоторые другие).Одна из моих целей в недавно сформированном проекте — создать решение, которое могло бы объединить все сборки платформы, что упрощает создание и тестирование изменений кода, поскольку вам не нужно открывать 3 разных решения только для тестирования вашего кода.Но для Visual Studio потребуются конфигурации 3* (количество базовых конфигураций).то естьОтладка ПК, отладка X360, отладка PS3 и т. д.

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

Однако у меня нет опыта работы с make-файлами в Visual Studio, и я хотел бы знать, есть ли у других опыт или проблемы, которыми они могут поделиться.

Спасибо.

(сообщение отредактировано, чтобы упомянуть, что это сборки C++)

Answer 1

Я обнаружил некоторые преимущества использования make-файлов в больших проектах, в основном связанные с унификацией расположения настроек проекта.Несколько проще управлять списком исходных файлов, включать пути, определения препроцессора и т. д., если все они находятся в make-файле или другом файле конфигурации сборки.При наличии нескольких конфигураций добавление пути включения означает, что вам необходимо обновлять каждую конфигурацию вручную с помощью неудобных свойств проекта Visual Studio, что может стать довольно утомительным по мере увеличения размера проекта.

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

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

Сразу на ум приходят минусы:

• Более медленные сборки:VS не особенно быстро вызывает внешние инструменты и даже не определяет, нужно ли вообще создавать проект.
• Неудобные межпроектные зависимости:Трудно настроить так, чтобы зависимый объект вызывал сборку базового проекта, и еще труднее следить за тем, чтобы они были построены в правильном порядке.Мне удалось убедить SCons сделать это, но добиться хорошей работы всегда непросто.
• Потеря некоторых полезных функций IDE:Редактировать и продолжать оставаться главным!

Короче говоря, вы потратите меньше времени на управление конфигурациями проекта, но больше времени на то, чтобы убедить Visual Studio правильно с ним работать.

Answer 2

Visual Studio строится на основе MSBuild файлы конфигурации.Вы можете рассматривать файлы *proj и *sln как файлы make.Они позволяют полностью настроить процесс сборки.

Answer 3

Хотя это технически возможно, это не очень удобное решение в Visual Studio.Он будет сражаться с вами все время.

Я рекомендую вам взглянуть на НАнт.Это очень надежная система сборки, в которой вы можете делать практически все, что вам нужно.

Наш скрипт NAnt делает это при каждой сборке:

1. Перенесите базу данных на последнюю версию
2. Генерация объектов C# из базы данных
3. Скомпилируйте каждый проект в нашем «главном» решении.
4. Запустите все модульные тесты
5. Запустите все интеграционные тесты

Кроме того, наш сервер сборки использует это и добавляет еще 1 задачу — создание документации Sandcastle.

Если вам не нравится XML, вы также можете взглянуть на Грабли (Рубин), Выпекать/BooBuildSystem (Бу), или Псаке (Пауэршелл)

Answer 4

Вы можете использовать nant для индивидуальной сборки проектов, заменяя таким образом решение, и иметь одно решение для кодирования и отсутствие решений для сборки.

Следует иметь в виду, что файлы Solution и csproj версии 2005 и более поздних версий представляют собой сценарии msbuild.Итак, если вы познакомитесь с msbuild, вы сможете использовать существующие файлы, чтобы упростить работу и упростить развертывание.

Answer 5

У нас есть аналогичный вариант, который вы описываете.Мы поддерживаем как минимум 3 разные платформы, поэтому мы обнаружили, что использование CMake для управления различными решениями Visual Studio.Настройка может быть немного болезненной, но в основном все сводится к чтению документации и пары руководств.Вы сможете делать практически все, что можете, перейдя к свойствам проектов и решений.Не уверен, что вы сможете объединить все три платформы в одном решении, но вы можете использовать Круиз-контроль заботиться о ваших сборках и запускать сценарии тестирования так часто, как это необходимо.