我来自Java背景,我目前工作的商店拒绝使用MS VC ++之外的任何东西来构建他们的遗留项目。他们似乎没有使用任何标准来设置他们的构建环境,只是使用VS2005构建它并单击编译按钮。
我想知道是否有更接近Java的东西:
或者我是否在C ++构建环境中提出过多要求?它总是像我店里的人一样混乱吗?考虑到互联网上如此众多的C ++项目的成功,我真的很难相信。
答案 0 :(得分:2)
听起来你有良好的愿望 - 从非MSVC世界来看,我可以看到你的观点。
如果我穿着鞋子,我肯定会制作一个命令行/自动构建/构建服务器。
你可以使用MSBuild - 而且hudson有一个插件。我通常在包含脚本/ etc的项目根目录附近有一个“Build”目录,它将调用相应的MSBuild / .sln文件。
Visual Studio的“makefile”是.sln和.vcproj文件。您可以从命令行调用msbuild。您还可以从可以运行的IDE中导出makefile(我认为这仍然是一个选项)。我不建议走那条路,除了试一试,看看输出是什么 - 因为这是你所熟悉的。
vcproj和sln文件都是人类可读的 - 通过它们 - 它会为您提供一些有用的信息。
我也同意有一个distributon目录是好的 - 在构建之后构建一个安装程序/ etc。在那里复制所有需要的二进制文件 - 在后构建步骤或其他脚本/等等。
让我们知道你最终在做什么。
我还有一条建议: 升级到VC / Dev studio 2008或2010.尽快
答案 1 :(得分:1)
MSVC不会对您施加任何目录结构。例如,如上面针对Debug和Release目录所述,有一些默认值,但即使是这些也可以基于每个项目进行覆盖。使用任何对你有意义的目录结构。
如果您不想使用IDE,Visual Studio会提供命令行支持。有关详细信息,请参阅This MSDN Article。
答案 2 :(得分:1)
您可以使用Visual Studio设置正确的构建环境(对于具有多个项目的解决方案,您应该),并且要在项目配置中使用许多环境变量来设置输出文件和中间文件转到与默认定义的文件夹不同的文件夹。
在我们的大型VS解决方案中,我们使用例如obj/$(ProjectName)/$(ConfigurationName)
作为中间目录,bin/$(ConfigurationName)
作为所有子项目中的输出目录。
所有这些事情必须由用户强制执行,似乎没有任何单一的推荐/最佳实践发展。
答案 3 :(得分:0)
标准化的东西:
*.sln
/ *.vcproj
(Visual Basic等*.vbproj
等)剩下的并不是“混乱”,因为“并不重要”。 “Chaotic”表明它一直在变化,但实际上你只需要选择一个项目并坚持下去。公司可能有跨项目的内部标准。打扰各公司的标准化并不重要。无论如何,C ++是一门复杂的语言;任何有足够智商来阅读C ++的人都可以处理合理的变化。 \lib\
和\Library\
之间的差异不会阻止它们。