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

Я знаю, что идеальный способ создания проектов - это не требовать файлы проекта на основе IDE, поскольку теоретически это вызывает всевозможные проблемы с автоматизацией, а с другими. Но мне еще предстоит работать над проектом, который компилируется в Windows и не зависит от проекта VisualStudio (хорошо, очевидно, что некоторые вещи с открытым исходным кодом выполняются с помощью Cygwin, но я здесь общий).

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

Так как же люди, использующие VS, на самом деле обрабатывают внешние make-файлы? Мне еще предстоит найти безболезненную систему для этого ...

Или на самом деле большинство людей этого не делают, хотя это считается хорошей практикой?

Ответов (11)

Решение

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

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

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

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

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

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

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

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

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

В идеале пожалуй, на практике нет.

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

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

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

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

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

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

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

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

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

Пример:

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

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

Зачем вам нужен проект, который «компилируется в 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:

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

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

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

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

project(hello)
add_executable(hello hello.cpp)

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

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

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

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

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

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

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