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.
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".
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).
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).
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 really slow 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.
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.
Is there anything more annoying than having to stop and wait for your tools? Are the benefits worth the frustration?
Thoughts, stories, help?
VS chugs to catch up with me.
Hmmm ... you machine needs more memory & grunt. Never had performance problems with mine.
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.
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.
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.
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.
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.
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!
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!
Also! ... We'd end up with a product that can run on both Windows and Linux!
Good luck!
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.
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 MingGW on 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.
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.
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?
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 Xming as the X server on your Windows machines.
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.
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.
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.
#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.
#roo
Using multiple compilers sounds like a pain. We have the luxury of just sticking with gcc for all our platforms.
#josh
Yikes! That sounds like a great way to introduce errors! :-)
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.
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.
So now I'm looking into using VS from Windows, even though my only build target is 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).
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.
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.
If anyone has any pointers for any of this, I'd really appreciate it.
Thanks,
Christophe
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.
We are using a similar solution to what you described.
We have our code stored on the Windows side of the world and UNIX (QNX 4.25 to be exact) has access though an NFS mount (thanks to UNIX services for Windows). We have an ssh into UNIX to run make and the pipe to output into VS. Accessing the code is fast, builds are a little slower than before, but our longest compile is currently less than two minutes, not a big deal.
Using VS for UNIX development has been worth the effort to set it up, because we now have IntelliSense. Less typing = happy developer.
Check out "Final Builder" (http://www.finalbuilder.com/). Select a version control system (e.g. cvs or svn, to be honest, cvs would suit this particular use case better by the sounds of it) and then set up build triggers on FinalBuilder so that checkins cause a compile and send the results back to you.
You can set up rulesets in FinalBuilder that prevent you checking in / merging broken code into the baseline or certain branch folders but allow it to others (we don't allow broken commits to /baseline or /branches/*, but we have a /wip/ branching folder for devs who need to share potentially broken code or just want to be able to commit at the end of the day).
You can distribuite FB over multiple "build servers" so that you don't wind up with 20 people trying to build on one box, or waiting for one box to process all the little bitty commits.
Our project has a Linux-based server with Mac and Win clients, all sharing a common codebase. This set up works ridiculously well for us.
I'm doing the exact same thing at work. The setup I use is VS for Windows development, with a Linux VM running under VirtualBox for local build / execute verification. VirtualBox has a facility where you can make a folder on the host OS (Windows 7 in my case) available as a mountable filesystem in the guest (Ubuntu LTS 12.04 in my case). That way, after I start a VS build, and it's saved the files, I can immediately start a make under Linux to verify it builds and runs OK there.
We use SVN for source control, the final target is a Linux machine (it's a game server), so that uses the same makefile as my local Linux build. That way, if I add a file to the project / change a compiler option, usuall adding / changing a -D, I do the modifications initially under VS, and then immediately change the Linus makefile to reflect the same changes. Then when I commit, the build system (Bamboo) picks up the change, and does its own verification build.
Hard earned experience says this is an order of magnitude easier if you build like this from day one.
The first project I worked on started as Windows only, I was hired to port it to Linux, since they wanted to switch to a homogenous server environment, and everything else was Linux. Retrofitting a Windows project into this sort of a setup was a fairly major expenditure of effort.
Project number two was done "two system build" right from day one. We wanted to maintain the ability to use VS for development / debug since it is a very polished IDE, but we also had the requirement for final deploy to Linux servers. As I alluded to above, when the project was build with this in mind right from the start, it was quite painless. The worst part was a single file: system_os.cpp that contained OS specific routines, things like "get current time since linux epoch start in milliseconds", etc. etc. etc.
At the risk of getting a little off topic, we also created unit tests for this, and having the unit tests for the OS specific pieces provided a great deal of confidence that they worked the same on both platforms.
Related
I'm going to enter a small game competition in the coming months. They require the submission to be able to be compiled ( and it will be, before being run/evaluated for the contest) on Linux. I'm going to be using SDL and C++. I've only ever developed on Windows before and I've grown quite accustomed to the benefits Visual Studio gives. I'd like to be able to develop in windows with VS, and then near the end of the process migrate it over to linux. Beside making sure SDL is already installed on the Linux machine, are there things I can do throughout development that will make the process easier? Also, the contest rule for all of this states:
it must also work on an open platform (we strongly recommend making sure that your program run on modern flavors of GNU/Linux, as all of the judges will have access to it).
I assume compiling/running in Ubuntu (already have a home server with this) would be sufficient for this?
Your question is slightly open-ended, but my first suggestion would be to use a proper cross-platform build system such as CMake from day one. I would refrain from "migrating" to Linux at the very end; you may be under a rough schedule (and maybe run into problems you did not anticipate). Thus, a continuous build of (working) Linux versions will help ease your worries.
Furthermore, if the game is meant to run solely under Linux, why not install Ubuntu in a Virtual Machine somewhere and get acquainted with one of the development environments such as kdevelop or qtcreator? Wouldn't direct contact with the platform you are developing for make things a little easier?
I'm developing games and started like you. I'd advise you to use SFML library for this purposes. It's not very big and is very good thing to start from.
There you can use:
2D renderer (OpenGL)
Fonts
Timers
Wrappers around images/sprites
Post effects/shaders
Sound
Network
In this page you can find a few start examples.
I'm looking to implement a build server for Qt-based C++ projects. The server needs to check out the necessary code / assets from Subversion, build the executable files, assemble the artifacts for installation projects, and build the installation media files. The target platforms and (rough) toolchains are:
Windows (32- and 64-bit): qmake, nmake, msbuild, wix toolchain. The end result is an installer EXE and DVD image.
Mac OS X: qmake, make, custom bash scripts to assemble package. The end result is an application bundle within a disk image and a DVD image.
Ubuntu (32- and 64-bit): qmake, make, debuild-based scripts. The end result is a collection of DEB files and a DVD image.
Fedora (32- and 64-bit): qmake, make, rpmbuild-based scripts. The end result is a collection of RPM files and a DVD image.
So that's at least 4 build agents (maybe more if 32- and 64-bit can't be done on the same box) and 7 configurations. Open-source projects are preferred, but that is not an absolute requirement.
Most of the tools I'm seeing seem to be catered to Java (Jenkins, CruiseControl, etc.) or .Net (CruiseControl.net, etc.) Can those be used with a C++ toolchain, or will I constantly be fighting the system? Anything that you have used in the past and found works well with Qt / C++?
I use Jenkins for building and packaging many C++ projects, based on qmake, cmake, and makefiles.
There are plugins for cmake, qmake, and msbuild, but any command line scripts can be run as well.
I have done packaging using Jenkins with no problems, as it is just another command line step in a project.
There are good plugins for monitoring the number of warnings/errors produced by the compiler (I normally use GCC).
It also has matrix builds which allow you to build a project several times with different combinations of compiler flags, pre-processor variables, platform, etc. One project I set up is a matrix build with 5 boolean preprocessor flags on two platforms, which then does 2^6=64 builds. These can take a bit of setting up to get correct.
Here you can read a quick example:
Continuous Integration Server - Hudson
I think that Hudson, jenkins and builbot are worth a try. Wasting a day or two evaluating and trying them with a quick example will help you to choose confidently.
Most of the tools I'm seeing seem to be catered to Java (Jenkins, CruiseControl, etc.) or .Net (CruiseControl.net, etc.) Can those be used with a C++ toolchain, or will I constantly be fighting the system? Anything that you have used in the past and found works well with Qt / C++?
Any reasonably capable CI system will have a piece that will allow you to execute any program you want for your build command.
Here's what I would consider:
Does the CI system run on your system(s) of choice
Does it allow you an easy way to view your logs
Does it integrate with your test runner
Does it integrate with your code coverage reports (e.g. BullseyeCoverage w/C++ & Qt)
Will it publish your files in a manner sensible for your needs
Will at provide an archive/store of files, if necessary (e.g. pdbs & lib*.so.debug)
If the CI system doesn't support feature X, will you have to write it for each supported OS/system
Is the CI system / UI easy for you to use.
I did the above using CruiseControl and most things were pretty easy. I wrote everything in make or qmake and simply called out to the command that I needed executed. For unit test and code coverage integration I output stuff to XML and transformed it to something supported by CruiseControl.
My recommendation, take a look at the recommended CI systems and examine them based on the criteria above.
I'm using buildbot for this. I've been using it for 4 years, and I feel very happy with it.
It is an application written in python, that runs on a server and can manage multiple clients on various OSes. I'm currently using Windows XP, Windows 7, Debian, Ubuntu and CentOS build slaves. My projects are C++, and one of them (the end user GUI) is made in Python. But we've also integrated with other frameworks, for other features than GUI.
What is really good about buildbot is that it works by running command lines on slaves. With this, you can do whatever you want. Even on Windows systems to compile using Visual Studio! From these command lines, you get all the output centralized on the server, and accessible.
You may also find alternatives on this site that references many of them.
Disclaimer: I looked at it 3 years ago, I don't know if it is still accurate.
Hudson or Jenkins is pretty good.
Jenkins is indeed pretty popular for developing such a custom service, even after all these years, considering the question is already 7 years old.
Felgo also offers a Continuous Integration and Delivery (CI/CD) service for Qt. It supports desktop platforms as well as iOS, Android and embedded targets. The full feature set is described in the blog post.
Disclaimer: I am a software developer at Felgo
It seems that Visual Studio and the tools you can use it is far superior to Eclipse and other Linux-platforms.
So does it make sense to cross-develop for Linux under Visual Studio, as long as the code is much the same?
I assume that you can easily share files.
Of course it depends a lot of what you know and project setup, but for the later, importing to VS might be easier than importing into Eclipse.
This is actually possible, but only if you have the right infrastructure in place on both Windows and Linux (or some other *nix variety). I used to worke for an investment bank where almost all work was done on Windows with VC++ and then moved to Solaris and recompiled. This allowed us to use the far superior (over Solaris) Windows tools. And we are talking of building multi-tier, multi-threaded servers here.
However, in order to get this to work they had put in a massive effort (I would guess about 15 man-years) in terms of senior developer time. And it was kind of worth it because Solaris development tools are pants (but the Linux ones are actually quite good). It's not something you, as an individual developer are going to find particularly easy to do, unless you are writing generic command line utilities. In which case you can do it - I routinely recompile my Windows command-line projects on Linux.
The difficult part, in my opinion, is maintaining the separate build systems. If you start the project using Visual Studio you will be tempted to setup the project using the Visual Studio build system.
Don't do that.
Instead, I recommend trying CMake. Make the build system build using CMake, and then work from that starting point.
If I had to choose between Visual Studio and Emacs, I'd go with Emacs. The fact that Visual Studio seems superior to you is just because you got used to it and don't know how to do your usual workflow using other tools. Eclipse, after all, might not be the best choice for Windows developer to move to Linux. I'd also take a look at Qt Creator.
I am doing some C++ cross development - been doing that for a while on Windows and recently started on Unix.
I suppose what I am after is to simplify Unix development experience - I have a local windows box I do development on, and a remote Solaris box which I use to compile and test code on unix environment.
What I do now - I develop, compiled and test code on Windows (VC++) and once it is done, I move code to Solaris box using Filezilla over SSH. I also use Putty to connect to Solaris box and execute shell commands.
Since I am quite new to unix development - I suppose what I do is by far not optimal and the tools/technics I use not optimal too.
Can you recommend me a better tools - how to move code around more easily and may be a replacement for Putty (which looks quite outdated anyway).
Thanks.
If by any chance you want to run the same C++ IDE on both Windows and Solaris, I recommend taking a look at Code::Blocks. Also, as I suggested to Charles, running an X server on the Windows box gives you a lot more flexibility than running Putty or similar.
Is there any reason that You can't test software on Solaris using Virtual Machine? They can share folders so there is no need to uploading code to remote machine.
Second: use svn or git or mercurial. In one machine You check in your code, on other you checkout plus You have history of changes. No need to use Filezilla over SSH.
edit:
Also, I think that it would be good to use cmake (or scons - but I don't used it) to generating build files. For example - cmake generates Makefiles or project files for Your IDE, so You don't need to maintaint few different files that build Your code on different platforms.
You might want to look into Samba, so you can work directly with the Windows file explorer to move files to and from Windows/Unix environments, rather than using FTP.
But for UNIX shell access via Windows, you really can't beat Putty.
I recommend mercurial.
Just use a version control system such as Subversion or Mercurial. I strongly recommend the latter because it's distributed so you don't need to have a server per say and you can work offline. Every time you want to shove your Windows code to the unix machine you just need to do 'hg push' and off you go. To sort out the build you can with good old Make or just use SCons (again I prefer the latter because it comes with the power of Python).
I actually, very recently developed a cross platform project in C++ using wxWidgets and GraphicsMagick. I wrote it all in Mac OS X and then compiled both in Windows and Linux. One thing I'd like to point out is that GCC seems to be more pedantic about compile warnings and errors than Microsoft's compiler so if you grow to like the Unix environment I'd recommend to develop there and then compile in Windows (maybe even using a VMWare image).
Instead of moving your source code around manually, consider using a version control system. Not necessarily a distributed VCS such as git or mercurial, but you should use version control nonetheless.
Sooner or later, you'll need to use a debugger on the Unix machine, and if you prefer using a graphic debugger, you should install a local X server on your Windows machine.
IMHO vim is quite good editor ;)
gcc, nm, ld for compilation/build/diagnosis
makefile for builds
gdb as debugger, if you prefer GUI check ddd (if you want to stick
with Visual Studio for debugging
check www.vsbridge.com or
www.wingdb.com - they both
depends on gdb as back-end)
other commercial debugger for Unixes
is TotalView
(http://www.roguewave.com/products/totalview.aspx the price is
high, although they have their own
engine instead of gdb)
CVS, SVN as source control
If you want to edit files in VisualStudio you can use e.g. Samba as "transparent file system" ;)
By the way VirtualBox may be very helpful (I debug (Open)Solaris or Linux as VBox machines very frequently).
ps
yet another environment you may be interested in is Magic C++ www.magicunix.com/
I have an Open Source app and I have it working on Windows, Linux and Macintosh ( it's in C++ and built with gcc ). I've only tested it on a few different flavors of Linux so I don't know if it compiles and runs on all different Linux versions. Is there a place where I can upload my code and have it tested across a bunch of different systems like other Linux flavors and things like, Solaris, FreeBSD and other operating systems?
What would be great is if I can have it directly connect to my svn repository and grab the latest code and then email me back any compile errors generated and what the OS was that it had a problem with.
I would be happy to just know it compiles as it is a GUI based app so I wouldn't expect it to actually be ran and tested.
There are a few options but there don't appear to be many (any?) free services like this, which isn't surprising considering the amount of effort and resources it requires. Sourceforge used to operate a compile farm like what you describe but it shut down a year or so ago. You might look into some of the following. If you're inclined to pay for a service or roll your own, then some of these links may be useful. If you're just looking for a free open source compile/build farm that covers multiple platforms it looks like you're pretty much out of luck.
OpenSuse Build Service
Mentioned by Ted first, worth repeating - only for Linux currently but does support a number of distros.
GCC Compile Farm
Mainly focused on testing builds for GCC but does also host a few other projects such as coLinux, BTG BitTorrent client, ClamAV, and others. May be something you can take advantage of, though I don't see what OSes are in the compile farm (contains at least Linux and Solaris based on the page notes).
BuildLocker
BuildLocker is a Web-based continuous integration solution for Java and .NET projects. BuildLocker is a virtual dedicated build machine that helps teams find bugs earlier in the development cycle, saving time and money. BuildLocker manages scheduled automated builds of source code in your ProjectLocker Source Control repository. Just check in the source code, and scheduled builds validate the integrity of the code. BuildLocker can even run automated tests, and can alert you anytime a test fails.
CruiseControl
CruiseControl is a framework for a continuous build process. It includes, but is not limited to, plugins for email notification, Ant, and various source control tools. A web interface is provided to view the details of the current and previous builds.
Interesting side note, CruiseControl is actually used by StackOverflow's dev team for automated build testing as well, according to the podcast.
Hudson
Hudson monitors executions of repeated jobs, such as building a software project or jobs run by cron.
RunCodeRun
Mentioned in the other linked question, only supports Ruby projects and is in private beta currently. However, if your project is in Ruby, it might be worth keeping an eye on RunCodeRun.
CI Feature Matrix
There are many Continuous Integration systems available. This page is an attempt to keep an unbiased comparison of as many as possible of them.
Take a look at the OpenSuSE build service, it includes a fairly wide variety of Linux distros (not just SuSE/OpenSuSE).
From a software point of view, there's also buildbot (sourceforge project site), which can be used to set up your own build/continous integration server.
This was suggested and considered to be used for gcc development (as mentioned on the gcc compile farm wiki page posted above).
If you are planning to go commercial with your open source product you might consider our Parabuild. It allows you to run a set of builds on multiple platforms and machines in parallel. The build will success only if all platform-specific builds success.