Хорошие методы использования Makefiles в VisualStudio?

Мы используем NAnt-скрипт, который на этапе компиляции вызывает MSBuild. Использование NAnt позволяет нам выполнять задачи как до, так и после сборки, такие как установка номеров версий в соответствии с номерами версий системы управления версиями, сопоставление информации о покрытии кода, сборка и архивирование источников развертывания. Но, тем не менее, в основе всего лежит MSBuild, который на самом деле выполняет компиляцию.

Вы можете интегрировать сборку NAnt в качестве пользовательского инструмента в IDE, чтобы ее можно было использовать как на сервере сборки или непрерывной интеграции, так и разработчиками таким же образом.

Взгляните на MSBuild!

• MSBuild может работать с файлами sln/csproj из VS, поэтому для простых проектов вы можете просто вызывать их напрямую.
• если вам нужно больше контроля, оберните проекты в свой собственный процесс сборки, добавьте свои собственные задачи и т. д. - это очень расширяемо!

(Я хотел добавить образец, но этот редактор полностью испортил XML... извините)

В идеале возможно, на практике нет.

Я бы предпочел Makefiles в качестве мастера сборки, однако разработчики проводят все свое время внутри Visual Studio IDE, и когда они вносят изменения, они вносят изменения в файл vcproj, а не в makefile. Поэтому, если я делаю глобальные сборки с помощью make-файлов, это слишком легко рассинхронизируется с файлами проекта/решения, используемыми 8 или 10 другими.

Единственный способ, которым я могу идти в ногу со всей командой, — запустить devenv.exe для файлов решений непосредственно в моих сценариях процесса сборки.

В моих билдах очень мало make-файлов, где они есть в разделах pre-build или custom build или в отдельном служебном проекте.

Одна из возможностей — использовать CMake — вы описываете с помощью сценария, как выполняется ваш проект. для сборки, а CMake создаст для вас файлы решения/проекта Visual Studio.

А если вам нужно собрать свой проект из командной строки или в инструменте непрерывной интеграции, вы используете CMake для создания файла Makefile для NMake.

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

Простой скрипт CMake выглядит так:

project(hello)
add_executable(hello hello.cpp)

Сравните эти две строки с make-файлом или с тем, как вы настраиваете простой проект в своей любимой IDE.

В двух словах, CMake не только кросс-платформен – позволяет вашему проекту, но и делает его кросс-IDE. Если вы хотите просто протестировать свой проект с помощью eclipse, KDevelop или codeblocks, просто запустите CMake, чтобы сгенерировать соответствующие файлы проекта.

Что ж, на практике это не всегда так просто, но идея CMake просто потрясающая.

Например, если вы планируете использовать CMake с Visual Studio, потребуется некоторая настройка, чтобы получить знакомое ощущение проекта VS, основным препятствием является организация ваших заголовочных и исходных файлов, но это возможно - проверьте вики CMake (и написав краткий script, вы можете даже упростить эту задачу).

Лично я использую Rake для вызова msbuild в моем решении или проекте. Для регулярной разработки я использую IDE и все ее преимущества.

Rake настроен так, что я могу просто компилировать, компилировать и запускать тесты или компилировать запуск тестов и создавать развертываемые артефакты. .

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

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

Мы используем devenv.exe (тот же исполняемый файл, который запускает IDE) для сборки наших проектов из сценариев сборки (или из командной строки). При указании параметра /Build IDE не отображается и все записывается обратно в консоль (или в лог-файл, если указан параметр /Out)

См. http://msdn.microsoft.com/en-us/library/xee0c8y7(VS.80).aspx для получения дополнительной информации

Пример:

devenv.exe [имя-файла-решения] /Build [имя-проекта] /Rebuild "Release|Win32" /Out solution.log

где «Release|Win32» — это конфигурация, определенная в решении, а solution.log — это файл, который получает выходные данные компилятора (что очень удобно, когда вам нужно выяснить, что пошло не так при компиляции)

У нас есть программа, которая анализирует файлы vcproj и генерирует из них фрагменты makefile. (К ним относятся список файлов и #define, а также имеется некоторая ограниченная поддержка пользовательских шагов сборки.) Затем эти фрагменты включаются в главный make-файл, который выполняет обычные действия GNU make.

(Это все для одной из целевых систем; ее инструменты не имеют встроенной поддержки Visual Studio.)

Это не требовало большого объема работы. День на настройку, потом, может быть, день или два на решение некоторых проблем, которые не были очевидны сразу. И это работает довольно хорошо: настройки компилятора контролируются основным make-файлом (больше не нужно возиться с этими крошечными текстовыми полями), и все же любой может добавлять новые файлы и определения в сборку обычным способом.

Тем не менее, комбинаторные проблемы, присущие обработке Visual Studio конфигураций сборки, остаются.

Почему вы хотите иметь проект, который «компилируется в Windows и не зависит от проекта VisualStudio»? У вас уже есть файл решения — вы можете просто использовать его при сборке консоли.

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

Есть что-то, что мне не хватает?

Как насчет этого кода?

public TRunner CleanOutput()
{
    ScriptExecutionEnvironment.LogTaskStarted("Cleaning solution outputs");

    solution.ForEachProject(
        delegate (VSProjectInfo projectInfo)
            {             
                string projectOutputPath = GetProjectOutputPath(projectInfo.ProjectName);

                if (projectOutputPath == null)
                    return;

                projectOutputPath = Path.Combine(projectInfo.ProjectDirectoryPath, projectOutputPath);

                DeleteDirectory(projectOutputPath, false);

                string projectObjPath = String.Format(
                    CultureInfo.InvariantCulture,
                    @"{0}\obj\{1}",
                    projectInfo.ProjectName,
                    buildConfiguration);
                projectObjPath = Path.Combine(productRootDir, projectObjPath);
                DeleteDirectory(projectObjPath, false);
            });

    ScriptExecutionEnvironment.LogTaskFinished();
    return ReturnThisTRunner();
}

public TRunner CompileSolution()
{
    ScriptExecutionEnvironment.LogTaskStarted ("Compiling the solution");

    ProgramRunner
        .AddArgument(MakePathFromRootDir(productId) + ".sln")
        .AddArgument("/p:Configuration={0}", buildConfiguration)
        .AddArgument("/p:Platform=Any CPU")
        .AddArgument("/consoleloggerparameters:NoSummary")
        .Run(@"C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe");

    ScriptExecutionEnvironment.LogTaskFinished ();
    return ReturnThisTRunner ();
}

Остальную часть можно найти здесь: http://code.google.com/p/projectpilot/source/browse/trunk/Flubu/Builds/BuildRunner.cs

Я еще не пробовал это сам, но у Microsoft есть реализация Make под названием NMake, которая, похоже, имеет интеграцию с Visual Studio:

• NMake
• Создание проектов NMake

Visual Studio, начиная с VS2005, использует «msbuild» для определения и запуска сборок. Когда вы возитесь с настройками проекта в конструкторе Visual Studio — скажем, вы включаете или отключаете создание документов XML, добавляете новую зависимость или добавляете новый проект или ссылку на сборку — Visual Studio обновит файл .csproj (или . vbproj и т. д.), который является файлом msbuild.

Подобно Java ant или Nant до него, msbuild использует XML-схему для описания проекта и сборки. Он запускается из VS, когда вы делаете сборку «F6», и вы также можете запустить его из командной строки, даже не открывая VS и не запуская devenv.exe.

Итак, используйте инструмент VS для разработки и msbuild из командной строки для автоматизированной сборки — та же сборка и та же структура проекта.