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

Question

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

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

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

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

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

Спасибо.

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

Answer 1

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

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

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

Непосредственные отрицательные стороны, которые приходят на ум:

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

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

Answer 2

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

Answer 3

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

1 вещь, о которой нужно помнить, заключается в том, что файлы решений и csproj от vs 2005 и выше являются сценариями msbuild. Поэтому, если вы знакомы с msbuild, вы можете использовать существующие файлы, упростить и упростить развертывание.

Answer 4

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

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

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

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

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

Если вам не нравится XML, вы можете также взглянуть на Rake (рубиновый), Bake/BooBuildSystem (Boo), или Psake (PowerShell)

Answer 5

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