visual-studio 使用 Visual Studio 为 Unix 开发 C++

Using Visual Studio to develop for C++ for Unix

提问by Mike Baker

Does anyone have battle stories to share trying to use Visual Studio to develop applications for Unix? And I'm not talking using .NET with a Mono or Wine virtual platform running beneath.

有没有人可以分享尝试使用 Visual Studio 为 Unix 开发应用程序的战斗故事？我不是在谈论使用 .NET 和在其下运行的 Mono 或 Wine 虚拟平台。

Our company has about 20 developers all running Windows XP/Vista and developing primarily for Linux & Solaris. Until recently we all logged into a main Linux server and modified/built code the good old fashioned way: Emacs, Vi, dtpad - take your pick. Then someone said, "hey - we're living in the Dark Ages, we should be using an IDE".

我们公司有大约 20 名开发人员，他们都运行 Windows XP/Vista，主要为 Linux 和 Solaris 开发。直到最近，我们都登录到一个主要的 Linux 服务器并以老式的方式修改/构建代码：Emacs、Vi、dtpad - 随你选择。然后有人说，“嘿 - 我们生活在黑暗时代，我们应该使用 IDE”。

So we tried out a few and decided that Visual Studio was the only one that would meet our performance needs (yes, I'm sure that IDE X is a very nice IDE, but we chose VS).

所以我们尝试了一些，并决定 Visual Studio 是唯一能够满足我们性能需求的（是的，我确信 IDE X 是一个非常好的 IDE，但我们选择了 VS）。

The problem is, how do you setup your environment to have the files available locally to VS, but also available to a build server? We settled with writing a Visual Studio plugin - it writes our files locally and to the build server whenever we hit "Save" and we have a bit fat "sync" button that we can push when our files change on the server side (for when we update to the latest files from our source control server).

问题是，您如何设置环境以使文件在 VS 本地可用，但也可用于构建服务器？我们决定编写一个 Visual Studio 插件 - 它会在我们点击“保存”时将我们的文件写入本地并写入构建服务器，并且我们有一个有点胖的“同步”按钮，当我们的文件在服务器端发生变化时我们可以按下它（何时我们从源代码管理服务器更新到最新文件）。

The plugin also uses Visual Studio's external build system feature that ultimately just ssh's into the build server and calls our local "make" utility (which is Boost Build v2 - has great dependency checking, but is reallyslow to start as a result i.e. 30-60 seconds to begin). The results are piped back into Visual Studio so the developer can click on the error and be taken to the appropriate line of code (quite slick actually). The build server uses GCC and cross-compiles all of our Solaris builds.

该插件还使用 Visual Studio 的外部构建系统功能，最终只是通过 ssh 进入构建服务器并调用我们本地的“make”实用程序（即 Boost Build v2 - 具有很好的依赖性检查，但因此启动速度非常慢，即 30- 60 秒开始）。结果通过管道返回到 Visual Studio，因此开发人员可以单击错误并转到适当的代码行（实际上非​​常流畅）。构建服务器使用 GCC 并交叉编译我们所有的 Solaris 构建。

But even after we've done all this, I can't help but sigh whenever I start to write code in Visual Studio. I click a file, start typing, and VS chugs to catch up with me.

但即使我们完成了这一切，每当我开始在 Visual Studio 中编写代码时，我都会忍不住感叹。我点击一个文件，开始打字，然后 VS 突突来追上我。

Is there anything more annoying than having to stop and wait for your tools? Are the benefits worth the frustration?

有什么比不得不停下来等待你的工具更烦人的吗？这些好处值得沮丧吗？

Thoughts, stories, help?

想法，故事，帮助？

回答by magius

VS chugs to catch up with me.
Hmmm ... you machine needs more memory & grunt. Never had performance problems with mine.

VS突突赶上我。
嗯......你的机器需要更多的内存和咕噜声。我的从来没有性能问题。

I've about a decade's experience doing exactly what you're proposing, most of it in the finance industry, developing real-time systems for customers in the banking, stock exchanges, stock brokerage niches.

我有大约十年的经验，完全按照你的建议去做，其中大部分是在金融行业，为银行、证券交易所、股票经纪行业的客户开发实时系统。

Before proceeding further, I need to confess that all this was done in VS6 + CVS, and of late, SVN.

在继续之前，我需要承认所有这些都是在 VS6 + CVS 以及最近的 SVN 中完成的。

Source Code Versioning

源代码版本控制

Developers have separate sourcesafe repositories so that they can store their work and check it packages of work at logical milestones. When they feel they want to do an integration test, we run a script that checks it into SVN.

开发人员拥有单独的源安全存储库，以便他们可以存储他们的工作并在逻辑里程碑处检查工作包。当他们觉得要进行集成测试时，我们会运行一个脚本将其检入 SVN。

Once checked into SVN, we've a process that kicks off that will automatically generate relevant makefiles to compile them on the target machines for continuous integration.

一旦签入 SVN，我们就会启动一个过程，该过程将自动生成相关的 makefile 以在目标机器上编译它们以进行持续集成。

We've another set of scripts that synchs new stuff from SVN to the folders that VS looks after. There's a bit of gap because VS can't automatically pick up new files; we usually handle that manually. This only happens regularly the first few days of the project.

我们还有另一组脚本，可以将 SVN 中的新内容同步到 VS 管理的文件夹中。有一点差距，因为 VS 不能自动拾取新文件；我们通常手动处理。这只会在项目的前几天定期发生。

That's an overview of how we maintain codes. I have to say, I've probably glossed over some details (let me know if you're interested).

这是我们如何维护代码的概述。我不得不说，我可能掩盖了一些细节（如果你有兴趣，请告诉我）。

Coding

编码

From the coding aspect, we rely heavily on the pre-processors (i.e. #define, etc) and flags in the makefile to shape compilation process. For cross platform portability, we use GCC. A few times, we were force to use aCC on HP-UX and some other compilers, but we did not have much grief. The only thing that is a constant pain, is that we had to watch out for thread heap spaces across platforms. The compiler does not spare us from that.

从编码方面来看，我们非常依赖生成文件中的预处理器（即#define 等）和标志来塑造编译过程。为了跨平台可移植性，我们使用 GCC。有几次，我们被迫在 HP-UX 和其他一些编译器上使用 aCC，但我们并没有太多悲伤。唯一令人痛苦的是，我们必须注意跨平台的线程堆空间。编译器不会让我们免于这一点。

Why?

为什么？

The question is usually, "Why the h*ll would you even what to have such a complicated way of development?". Our answer is usually another question that goes, "Have you any clue how insane it is to debug a multi-threaded application by examining the core dump or using gdb?". Basically, the fact that we can trace/step through each line of code when you're debugging an obscure bug, makes it all worth the effort!

问题通常是，“你为什么要拥有如此复杂的开发方式？”。我们的回答通常是另一个问题，“您知道通过检查核心转储或使用 gdb 来调试多线程应用程序是多么疯狂吗？”。基本上，当您调试一个不起眼的错误时，我们可以跟踪/逐步执行每一行代码，这一事实使一切努力都值得！

Plus!... VS's intellisense feature makes it so easy to find the method/attribute belonging to classes. I also heard the VS2008 has refactoring capabilities. I've shifted my focus to Java on Eclipse that has both features. You'd be more productive focusing coding business logic rather than devote energy making your mind do stuff like remember!

另外！... VS 的智能感知功能可以很容易地找到属于类的方法/属性。我也听说 VS2008 有重构功能。我已将注意力转移到同时具有这两个功能的 Eclipse 上的 Java。你会更有效率地专注于编码业务逻辑，而不是投入精力让你的大脑做诸如记住之类的事情！

Also! ... We'd end up with a product that can run on both Windows and Linux!

还！...我们最终会得到一个可以在 Windows 和 Linux 上运行的产品！

Good luck!

祝你好运！

回答by roo

I feel your pain. We have an application which is 'cross-platform'. A typical client/server application where the client needs to be able to run on windows and linux. Since our client base mostly uses windows we work using VS2008 (the debugger makes life a lot easier) - however we still need to perform linux builds.

我感觉到你的痛苦。我们有一个“跨平台”的应用程序。一个典型的客户端/服务器应用程序，其中客户端需要能够在 windows 和 linux 上运行。由于我们的客户群主要使用 windows，我们使用 VS2008（调试器使生活更轻松） - 但是我们仍然需要执行 linux 构建。

The major problem with this was we were checking in code that we didn't know would build under gcc, which would more than likely break the CI stuff we had setup. So we installed MingGWon all our developer's machines which allows us to test that working copy will build under gcc before we commit it back to the repository.

这样做的主要问题是我们正在检查我们不知道会在 gcc 下构建的代码，这很可能会破坏我们设置的 CI 东西。因此，我们在所有开发人员的机器上安装了MingGW，这允许我们在将其提交回存储库之前测试将在 gcc 下构建的工作副本。

回答by David Sykes

We develop for Mac and PC. We just work locally in whatever ide we prefer, mostly VS but also xcode. When we feel our changes are stable enough for the build servers we check them in. The two build servers (Mac and PC) look for source control checkins, and each does a build. Build errors are emailed back to the team.

我们为 Mac 和 PC 开发。我们只是在我们喜欢的任何 ide 中本地工作，主要是 VS 但也有 xcode。当我们觉得我们的更改对于构建服务器来说足够稳定时，我们将它们签入。两个构建服务器（Mac 和 PC）寻找源代码控制签入，并且每个都执行一个构建。构建错误通过电子邮件发送给团队。

Editing files live on the build server sounds precarious to me. What happens if you request a build while another developer has edits that won't build?

在构建服务器上实时编辑文件对我来说听起来很不稳定。如果您请求构建​​而另一个开发人员进行了无法构建的编辑，会发生什么情况？

回答by supercheetah

I know this doesn't really answer your question, but you might want to consider setting up remote X sessions, and just run something like KDevelop, which, by the way, is a very nice IDE--or even Eclipse, which is more mainstream, and has a broader developer base. You could probably just use something like Xmingas the X server on your Windows machines.

我知道这并不能真正回答您的问题，但您可能想考虑设置远程 X 会话，然后运行KDevelop 之类的东西，顺便说一下，它是一个非常好的 IDE——甚至是Eclipse，它更主流，并拥有更广泛的开发人员基础。您可能只使用Xming 之类的东西作为 Windows 机器上的 X 服务器。

回答by bmdhacks

I've had good experience developing Playstation2 code in Visual Studio using gcc in cygwin. If you've got cygwin with gcc and glibc, it should be nearly identical to your target environments. The fact that you have to be portable across Solaris and Linux hints that cygwin should work just fine.

我在cygwin 中使用 gcc 在 Visual Studio 中开发 Playstation2 代码方面有很好的经验。如果您有带有 gcc 和 glibc 的 cygwin，它应该与您的目标环境几乎相同。您必须在 Solaris 和 Linux 之间具有可移植性这一事实暗示 cygwin 应该可以正常工作。

回答by bmdhacks

Most of my programming experience is in Windows and I'm a big fan of visual studio (especially with Resharper, if you happen to be doing C# coding). These days I've been writing an application for linux in C++. After trying all the IDEs (Netbeans, KDevelop, Eclipse CDT, etc), I found Netbeans to be the least crappy. For me, absolute minimum requirements are that I be able to single-step through code and that I have intellisense, with ideally some refactoring functions as well. It's amazing to me how today's linux IDE's are not even close to what Visual Studio 6 was over ten years ago. The biggest pain point right now is how slow and poorly implemented the intellisense in Netbeans is. It takes 2-3 seconds to populate on a fast machine with 8GB of RAM. Eclipse CDT's intellisense was even more laggy. I'm sorry, but a 2 second wait for intellisense doesn't cut it.

我的大部分编程经验都是在 Windows 中进行的，而且我是 Visual Studio 的忠实粉丝（尤其是使用 Resharper，如果您碰巧在进行 C# 编码）。这些天我一直在用 C++ 为 linux 编写一个应用程序。在尝试了所有的 IDE（Netbeans、KDevelop、Eclipse CDT 等）之后，我发现 Netbeans 是最糟糕的。对我来说，绝对最低要求是我能够单步执行代码并且我有智能感知，理想情况下还有一些重构功能。令我惊讶的是，今天的 linux IDE 与十多年前的 Visual Studio 6 相差甚远。现在最大的痛点是在 Netbeans 中实现智能感知的速度有多慢和很差。在具有 8GB RAM 的快速机器上填充需要 2-3 秒。Eclipse CDT 的智能感知更加滞后。抱歉，

So now I'm looking into using VS from Windows, even though my only build target is linux...

所以现在我正在考虑从 Windows 使用 VS，即使我唯一的构建目标是 linux...

Chris, you might want to look at the free automation build server 'CruiseControl', which integrates with all main source control systems (svn, tfs, sourcesafe, etc.). It's whole purpose is to react to check-ins in a source control system. In general, you configure it so that anytime anyone checks code in, a build is initiated and (ideally) unit tests are run. For some languages there are some great plugins that do code analysis, measure unit test code coverage, etc. Notifications are sent back to the team about successful / broken builds. Here's a post describing how it can be set up for C++: link (thoughtworks.org).

克里斯，您可能想看看免费的自动化构建服务器“CruiseControl”，它与所有主要的源代码控制系统（svn、tfs、sourcesafe 等）集成在一起。它的全部目的是对源代码控制系统中的签入做出反应。通常，您对其进行配置，以便任何人在任何时候签入代码时，都会启动构建并（理想情况下）运行单元测试。对于某些语言，有一些很棒的插件可以进行代码分析、测量单元测试代码覆盖率等。有关成功/损坏构建的通知会发送回团队。这是一篇描述如何为 C++ 设置它的帖子：link (thoughtworks.org)。

I'm just getting started with converting from a linux-only simple config (Netbeans + SVN, with no build automation) to using Windows VS 2008 with build automation back-end that runs unit tests in addition to doing builds in linux. I shudder at the amount of time it's going to take me to get that all configured, but the sooner the better, I guess.

我刚刚开始从仅 linux 的简单配置（Netbeans + SVN，没有构建自动化）转换为使用 Windows VS 2008 和构建自动化后端，除了在 linux 中进行构建之外，还运行单元测试。我对完成所有配置所需的时间感到不寒而栗，但我想越快越好。

In my ideal end-state I'll be able to auto-generate the Netbeans project file from the VS project, so that when I need to debug something in linux I can do so from that IDE. VS project files are XML-based, so that shouldn't be too hard.

在我理想的最终状态中，我将能够从 VS 项目自动生成 Netbeans 项目文件，这样当我需要在 linux 中调试某些东西时，我可以从该 IDE 中进行。VS 项目文件是基于 XML 的，所以应该不会太难。

If anyone has any pointers for any of this, I'd really appreciate it.

如果有人对此有任何指示，我将不胜感激。

Thanks,

谢谢，

Christophe

克里斯托夫

回答by Mike Kale

You could have developers work in private branches (easier if you're using a DVCS). Then, when you want to checkin some code, you check it into your private branch on [windows|unix], update your sandbox on [unix|windows] and build/test before committing back to the main branch.

您可以让开发人员在私人分支机构工作（如果您使用的是 DVCS，则更容易）。然后，当你想签入一些代码时，你将它签入你在 [windows|unix] 上的私有分支，在 [unix|windows] 上更新你的沙箱并在提交回主分支之前构建/测试。

回答by Judge Maygarden

Wow, that sounds like a really strange use for Visual Studio. I'm very happy chugging away in vim. However, the one thing I love about Visual Studio is the debugger. It sounds like you are not even using it.

哇，这对 Visual Studio 来说听起来很奇怪。我很高兴在 vim 中闲逛。但是，我喜欢 Visual Studio 的一件事是调试器。听起来你甚至没有使用它。

When I opened the question I thought you must be referring to developing portable applications in Visual Studio and then migrating them to Solaris. I have done this and had pleasant experiences with it.

当我打开这个问题时，我认为您一定是指在 Visual Studio 中开发可移植应用程序，然后将它们迁移到 Solaris。我已经这样做了，并有愉快的经历。

回答by Josh

Network shares.

网络共享。

Of course, then you have killer lag on the network, but at least there's only one copy of your files.

当然，那么您在网络上会有致命的延迟，但至少您的文件只有一个副本。

You don't want to hear what I did when I was developing on both platforms. But you're going to: drag-n-drop copy a few times a day. Local build and run, and periodically checking it out on Unix to make sure gcc was happy and that the unit tests were happy on that platform too. Not really a rapid turnaround cycle there.

当我在两个平台上进行开发时，您不会想知道我做了什么。但是你要：每天拖放复制几次。本地构建和运行，并定期在 Unix 上检查它以确保 gcc 满意，并且单元测试在该平台上也满意。那里并不是真正的快速周转周期。

回答by Mike Baker

@monjardin

@monjardin

The main reason we use it is because of the re-factoring/search tools provided through Visual Assist X (by Whole Tomato). Although there are a number of other nice to haves like Intelli-sense. We are also investigating integrations with our other tools AccuRev, Bugzilla and Totalview to complete the environment.

我们使用它的主要原因是通过 Visual Assist X（由 Whole Tomato 提供）提供的重构/搜索工具。尽管还有许多其他的好东西，比如 Intelli-sense。我们还在研究与我们的其他工具 AccuRev、Bugzilla 和 Totalview 的集成以完成环境。

@roo

@roo

Using multiple compilers sounds like a pain. We have the luxury of just sticking with gcc for all our platforms.

使用多个编译器听起来很痛苦。我们有幸在所有平台上坚持使用 gcc。

@josh

@乔什

Yikes! That sounds like a great way to introduce errors! :-)

哎呀！这听起来是引入错误的好方法！:-)