Использование Makefile вместо файлов решения / проекта в Visual Studio (2005)
Есть ли у кого-нибудь опыт использования makefiles для сборки Visual Studio C++ (под VS 2005) В отличие от использования установки project/solution. Для нас способ работы проекта / решения не интуитивно понятен и приводит к взрыву конфигураций, когда вы пытаетесь настроить сборки с определенными флагами времени компиляции.
В Unix довольно легко настроить файл makefile, параметры которого по умолчанию переопределяются пользовательскими настройками (или другими настройками конфигурации). Но делать такие виды в Visual Studio все кажется сложным.
В качестве примера, у нас есть проект, который должен получить сборку для 3 различных платформ. Каждая платформа может иметь несколько конфигураций (например, debug, release и несколько других). Одна из моих целей в недавно созданном проекте-иметь решение, в котором все сборки платформы будут жить вместе, что упрощает создание и тестирование изменений кода, поскольку вам не нужно открывать 3 разных решения только для тестирования вашего кода. Но визуально студия потребует 3 * (количество базовых конфигураций) конфигураций. например, PC Debug, x360 Debug, PS3 Debug и т. д.
Похоже, что решение makefile здесь намного лучше. Обернутый некоторыми базовыми пакетами файлов или скриптами, было бы легко свести использование конфигурации к минимуму и поддерживать только небольшой набор файлов для всех различных сборок, которые мы должны сделать.
Однако у меня нет опыта работы с файлами Makefile в visual studio, и я хотел бы знать, есть ли другие есть опыт или проблемы, которыми они могут поделиться.
Спасибо.
(сообщение отредактировано, чтобы упомянуть, что это сборки C++)
5 ответов:
Я нашел некоторые преимущества для создания файлов с большими проектами, в основном связанные с унификацией расположения настроек проекта. Несколько проще управлять списком исходных файлов, включать пути, препроцессорные определения и т. д., Если все они находятся в файле makefile или другом файле конфигурации сборки. При наличии нескольких конфигураций добавление пути включения означает, что вам нужно убедиться, что вы обновляете каждую конфигурацию вручную через свойства проекта fiddly Visual Studio, что может быть довольно утомительно. проект растет в размерах.
Проекты, использующие множество пользовательских инструментов сборки, также могут быть проще в управлении, например, если вам нужно скомпилировать пиксельные / вершинные шейдеры или код на других языках без поддержки native VS.
Однако вам все равно потребуется иметь различные конфигурации проекта, так как вам нужно будет различать вызов инструмента сборки для каждой конфигурации (например, передавая различные параметры командной строки).
Непосредственные недостатки, которые приводят к УМ:
Короче говоря, вы потратите меньше времени на управление конфигурациями проекта, но больше времени на уговоры Visual Studio работать с ним должным образом.
- более медленные сборки: VS не особенно быстро вызывает внешние инструменты или даже решает, нужно ли ему создавать проект в первую очередь.
- неудобные межпроектные зависимости: это fiddly, чтобы настроить так, чтобы зависимый вызывал базовый проект для сборки, и fiddlier, чтобы убедиться, что они будут построены в правильном порядке. Я добился некоторого успеха, заставляя SCons делать это, но это всегда вызов, чтобы хорошо работать.
- потеря некоторых полезных IDE особенности: редактировать и продолжать быть главным!
Visual studio создается поверх конфигурационных файловMSBuild . Файлы *proj и *sln можно рассматривать как файлы Makefile. Они позволяют полностью настроить процесс сборки.
Хотя это технически возможно, это не очень дружественное решение в Visual Studio. Он будет бороться с тобой все время.
Я рекомендую вам взглянуть на NAnt . Это очень надежная система сборки, где вы можете делать практически все, что вам нужно.
Наш скрипт NAnt делает это на каждой сборке:
- перенос базы данных на последнюю версию
- генерировать сущности C# из базы данных
- компилируем каждый проект в нашем " мастере" решение
- Выполнить все модульные тесты
- Выполнить все интеграционные тесты
Кроме того, наш сервер сборки использует это и добавляет еще 1 задачу, которая генерирует документацию Sandcastle.
Если вам не нравится XML, вы можете также взглянуть на Rake (ruby), Bake/BooBuildSystem (Boo) или Psake (PowerShell)
Вы можете использовать nant для построения проектов по отдельности, таким образом заменяя решение и имея 1 решение для кодирования и никаких решений для сборки.
1 следует иметь в виду, что решение и файлы csproj от vs 2005 и выше являются сценариями msbuild. Таким образом, если вы познакомитесь с msbuild, вы сможете использовать существующие файлы, чтобы упростить vs и упростить развертывание.
У нас есть такая же установка, как та, которую вы описываете. Мы поддерживаем по крайней мере 3 различных платформы, поэтому мы обнаружили, что использование CMake для чесотки различных решений Visual Studio. Настройка может быть немного болезненной, но она в значительной степени сводится к чтению документов и нескольких учебных пособий. Вы должны быть в состоянии сделать практически все, что вы можете сделать, перейдя к свойствам проектов и решения. Не уверен, что вы можете иметь все три платформы строит жить вместе в то же самое решение, но вы можете использовать CruiseControl, чтобы заботиться о своих сборках и запускать свои тестовые сценарии так часто, как это необходимо.
Comments