我知道构建项目的理想方式是不需要基于IDE的项目文件,因为它理论上会导致自动化和其他方面的各种麻烦。但我还没有开发一个在Windows上编译的项目,它不依赖于VisualStudio项目(好吧,很明显一些开源的东西是用Cygwin完成的,但我在这里很普通。)
另一方面,如果我们只使用VS来运行makefile,我们就会失去编译选项窗口的所有好处,并且维护外部makefile会变得很麻烦。
那么使用VS的人如何实际处理外部makefile?我还没有找到一个无痛的系统来做到这一点......
或者实际上大多数人都没有这样做,虽然它被宣传为良好的做法?
答案 0 :(得分:5)
看看MSBuild!
(我想添加一个示例,但是这个edior完全弄乱了XML ...抱歉)
答案 1 :(得分:3)
一种可能性是使用CMake - 您使用脚本描述了如何构建项目,CMake会为您生成Visual Studio解决方案/项目文件。
如果您需要从命令行或持续集成工具构建项目,可以使用CMake为NMake生成Makefile。
如果您的项目是跨平台项目 - 您可以运行CMake为您选择的工具链生成makefile。
一个简单的CMake脚本如下所示:
project(hello)
add_executable(hello hello.cpp)
将这两行与makefile或您在自己喜欢的IDE中设置简单项目的方式进行比较。
简而言之,CMake不仅跨平台 - 启用您的项目,它还使跨IDE 。如果您只想使用eclipse或KDevelop或代码块测试项目,只需运行CMake即可生成相应的项目文件。
嗯,在实践中并不总是那么容易,但是CMake的想法只是摇滚。
例如,如果您考虑在Visual Studio中使用CMake,需要进行一些调整以获得熟悉的VS项目感觉,主要障碍是组织您的标题和源文件,但有可能 - 检查CMake维基(并通过写一个简短的脚本你甚至可以简化这个任务。)
答案 2 :(得分:2)
理想情况下,或许,在实践中没有。
Makefiles将是我作为构建大师的首选,但是,开发人员将所有时间都花在visual studio IDE中,当他们进行更改时,它是vcproj文件,而不是makefile。因此,如果我使用makefile进行全局构建,那么它很容易与8或10个其他项目/解决方案文件同步。
我与整个团队保持同步的唯一方法是直接在我的构建过程脚本中对解决方案文件运行devenv.exe。
我的构建中很少有makefile,它们位于预构建或自定义构建部分或单独的实用程序项目中。
答案 3 :(得分:2)
我们使用NAnt脚本,在编译步骤中调用MSBuild。使用NAnt允许我们执行构建前和构建后任务,例如设置版本号以匹配源控件修订号,整理代码覆盖率信息,组装和压缩部署源。但仍然,它的核心是MSBuild,它实际上正在进行编译。
您可以将NAnt构建作为自定义工具集成到IDE中,以便可以在构建或持续集成服务器上以及开发人员以相同方式使用它。
答案 4 :(得分:1)
就个人而言,我使用Rake在我的解决方案或项目上调用msbuild。对于常规开发,我使用IDE和提供的所有好处。
设置Rake以便我可以编译,编译和运行测试或编译运行测试并创建可部署的工件。
一旦你有了一个构建脚本,就可以很容易地开始做一些事情,比如设置持续集成并使用它来自动部署。
如果follow these steps to set it up,您还可以在IDE中使用大多数构建工具。
答案 5 :(得分:1)
我们使用devenv.exe(启动IDE的同一个exe)从构建脚本(或命令行)构建我们的项目。指定/ Build选项时,IDE不会显示,所有内容都会写回控制台(如果指定/ Out选项,则会写回日志文件)
有关详细信息,请参阅http://msdn.microsoft.com/en-us/library/xee0c8y7(VS.80).aspx
示例:
devenv.exe [solution-file-name] / Build [project-name] / Rebuild“Release | Win32”/ Out solution.log
其中“Release | Win32”是解决方案中定义的配置,solution.log是获取编译器输出的文件(当你需要弄清楚编译中出了什么问题时非常方便)
答案 6 :(得分:1)
我们有一个解析vcproj文件并从中生成makefile片段的程序。 (这些包括文件列表和#defines,并且对自定义构建步骤有一些有限的支持。)然后这些片段包含在make makefile中,该makefile执行通常的GNU make。
(这是我们所针对的系统之一;它的工具对Visual Studio没有本机支持。)
这不需要大量的工作。设置它的一天,然后可能总共一两天,以击败一些不明显的问题。它运行得相当好:编译器设置由主makefile控制(不再需要摆弄那些小文本框),但是任何人都可以添加新文件并以通常的方式定义构建。
尽管如此,Visual Studio对构建配置的处理所固有的组合问题仍然存在。
答案 7 :(得分:1)
为什么要让项目“在Windows上编译不依赖于VisualStudio项目”?您已经有了一个解决方案文件 - 您可以将它与控制台构建一起使用。
如果您的构建系统不像我们的那样复杂,我建议您将msbuild与makefile,nant甚至简单的批处理文件结合使用...
我有什么遗失的吗?
答案 8 :(得分:1)
这段代码怎么样?
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
答案 9 :(得分:1)
我自己还没有尝试过,但微软有一个名为NMake的Make实现,似乎有一个Visual Studio集成:
答案 10 :(得分:1)
自VS2005以来的Visual Studio,使用“msbuild”来定义和运行构建。当您在Visual Studio设计器中设置项目设置时 - 假设您打开或关闭XML文档生成,或者添加新的依赖项,或者添加新项目或程序集引用 - Visual Studio将更新.csproj(或。 vbproj等文件,这是一个msbuild文件。
与之前的Java蚂蚁或Nant一样,msbuild使用XML模式来描述项目和构建。当您执行“F6”构建时,它从VS运行,您也可以从命令行运行它,而无需打开VS或运行devenv.exe。
因此,使用VS工具进行开发,并使用命令行msbuild进行自动构建 - 相同的构建和相同的项目结构。