Хорошие методы для использования Makefiles в VisualStudio? - PullRequest
4 голосов
/ 27 февраля 2009

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

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

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

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

Ответы [ 11 ]

5 голосов
/ 24 марта 2009

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

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

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

3 голосов
/ 28 марта 2009

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

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

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

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

project(hello)
add_executable(hello hello.cpp)

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

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

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

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

2 голосов
/ 27 марта 2009

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

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

2 голосов
/ 27 февраля 2009

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

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

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

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

1 голос
/ 28 марта 2009

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

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

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

1 голос
/ 28 марта 2009

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

1 голос
/ 28 марта 2009

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

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

1 голос
/ 28 марта 2009

Зачем вам нужен проект, который "компилируется в Windows и не зависит от проекта VisualStudio"? У вас уже есть файл решения - вы можете просто использовать его со сборкой консоли.

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

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

1 голос
/ 22 марта 2009

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

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

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

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

1 голос
/ 22 марта 2009

Мы используем 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 - это файл, который получает выходные данные компилятора (что очень удобно, когда нужно выяснить, что пошло не так в компиляции)

...