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

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

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

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

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

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

Спасибо.

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

Ответ 1

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

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

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

Непосредственные недостатки, которые spring:

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

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

Ответ 2

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

Ответ 3

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

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

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

Перенос базы данных в последнюю версию
Сгенерировать объекты С# из базы данных
Скомпилируйте каждый проект в нашем "главном" решении.
Запуск всех модульных тестов
Запуск всех тестов интеграции

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

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

Ответ 4

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

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

Ответ 5

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