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

Question

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

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

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

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

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

Спасибо.

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

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

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

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