Slashdot Mirror
Scalable Windows Development Environments?
spirality asks: "I've been developing under *NIX since I started writing software about ten years ago, and my company has been developing its product under *NIX since its inception. Until recently that is. We just completed the first Windows version of our product. Under Unix we used CVS with a custom build environment that we developed in house, and it simply can not be ported to Windows. What are Slashdot users, who must develop under Windows, using for a development environment?"
"Though it does work under Cygwin, (this is how we got our port in place), it's simply not viable, as a simple compile/link cycle can sometimes take over an hour. We've begun to use Visual Studio, but have found that it lacks in many respects, especially when it comes to syncing project files among our developers. Obviously people are developing LOTS of Windows applications, and I can't imagine that everyone has a crippled development environment. What kinds of tools are used for source code revision, and especially what mode is Visual C++ used in? Given our dependence on third party libraries there is no way that we can avoid Visual C++, though use of the Microsoft IDE is not necessary. We have a team of about ten and are going to be adding more, so an environment that scales well is essential."
Since Borlands happy diversion with Kylix (happy for me) they have started taking the development process seriously and I think you should take a look at their product lifecyle tools.
http://www.borland.com/
They are taking very seriously the need for managing projects in all aspects.
Get an account manager to come and visit you and see what they suggest.
I had the speil a while back (2 years ago) but at the time it wasn't quite mature enough for the mobile patforms I was developing for, but I was impressed with the direction they were taking
Sam
blog.sam.liddicott.com
For cvs management, we use TortoiseCVS (http://www.tortoisecvs.org/). You can use Dev-C++ if you do not want to use Visual studio (http://sourceforge.net/projects/dev-cpp/) and you can use wxWidgets(wxWindows) if you want to develop cross platform GUIs (http://www.wxwidgets.org/)
My day job is a large C++/tcl application with thousands of source files. We build for Unix and for Windows.
.EXE file using Open Source software on Unix. And get some other poor fellow to do the testing on Windows.
Version control is done via RCS. The build is a non-recursive Makefile with correct dependency-checking. Individual programmers do not have complete copies of the source tree, but can substitute their working files for trunk files when linking the binary.
We use distcc and cross-compilers to build all our platforms.
One build step uses wine to run a Windows program, and another build step invokes msvc++ v6 in wine to build a DLL related to some third-party C++ software.
Our open-source, third-party libraries are rebuilt by a separate non-recursive-makefile, also using distcc and cross-compilers.
The biggest current problem with the setup is that a do-nothing build takes about 10 seconds, build 1 object + link takes nearly 1 minute, and all compiles in the office are serialized since they write to the same repository of object files.
Anyway, in summary, keep the horror that is Windows development far away from you, and build your
At my current place of employment we use Perforce for source control with their Visual Studio plugin. We use Visual Studio 2003 as our IDE and their compiler. Our project is about 1 million lines of code at the moment, so we use IncrediBuild for distributed compilation on development machines. It works similar to distcc. We use a bunch of Lua to launch builds on our build/"continous integration" machine.
At my previous place of employment we used Perforce and Visual Studio with Intel's compiler. And a bunch of Perl scripts to launch builds on our build machine.
What exactly are you having problems with?
While this works well for Windows-only development, it is NOT a portable build environment, so that might eliminate it from consideration.
Previously, I worked in a place where we hade success using a cross-compiler running in a DOS box under Windows, with the mks tooklit. However, the target there was an embedded system and not Windows.
You could've hired me.
We're a Borland Delphi / Oracle shop.
We configure our development environments within VMWare sessions running Windows 2000. Very little is running in the base OS. By putting our work into VMWare sessions, it allows us to roll-back our environments to a known state if necessary. Source code is kept on another server using CVS.
We bring the source down each day, do our work, then commit the changes to the CVS repository. Additionally, we back up our development VMs to the network. These same (stored) VMs can be access remotely when uploaded to our VMWare GSX server through the VPN.
This configuration has worked really well for us.
Subversion is a good replacement for CVS, and works on UN*X, OSX, and Windows (w/ command-line and explorer shell extensions).
Nothing to see here; Move along.
Now.. build system. How about something modern, cross-platform, that used Python scripts to control the build process...Sweet! I guess I'm all set then! Here's how you can get all of the above - for free:
* Scons build system (requires Python to be installed first).
* Subversion (SVN) version control system.
* Visual C++ 2003 Optimizing Compiler with the Windows Platform SDK.
* Microsoft Developer Network - free documentation and API reference (although this should be included in the platform SDK above).
* TortoiseSVN - a nice front-end to SVN on Windows. Included with the SVN installer by default.
* TortoiseMerge is included with TortoiseSVN, but you might also want to try WinMerge as an excellent stand-alone merge utility.
For editing code, you can use anything from Notepad to Edit to Emacs. I most frequently use the Microsoft Visual Studio IDE, but I also sometimes use the editor that comes with the Pythonwin extension package for Python as it also does syntax highlighting for C / C++ code.
Also note that any new programmers you hire with "Visual Studio" experience will be expecting to use the IDE. If you don't use external build tools, The VC project files are nothing more than text, so they can be merged quite nicely if you take a little time and effort. If you're each working on lots of different sections of code (and are used to having your own makefiles for each section), you can build libraries - each library having it's own
yes - windows environments are very crippled compared to *nix. Of course *nix environments are very crippled compared to punch cards, and punch card were very crippled compared to hand wiring backplanes.
Honestly, were do you get off calling windows environments crippled? For one, it's not windows, its the software you buy (or steal) and run under windows.
For two, just because you are used to using make, and don't have a similar archaic script based dinosaur in your windows environment does make your windows environment crippled, it makes it different, duh.
The number of commercial applications plus the number of enterprise applications, written in a crippled windows environment are sooo many times the number written in *nix environments it can not possibly be as big a problem as you make it out to be.
Granted I have never had a *nix budget ($10,000+ for a single license C++ compiler), but in looking at open source i find things like emacs, DDD, gcc and make to be extremly complicated. Yep, you can make em work, and you can make a punch card machnie work to, doesnt mean squat.
My current visual studio C# project has 20 + sub projects, persistent object libraries, business layers, GUI layers, both desktop and web and I hit ctrl-shift-b (build) and it builds. What is so crippled about that? Change a combo to NUnit and I can run component tests.
Oh - need overnight updates and builds?, well let's see the entire dev environment is exposed to scripting - so i can CVS update, build, run NUnit component tests and email results - yeah - real crippled alright.
Still not enough? There is an entire libray provided so that you can expand the environment.
It's not the windows environment that's crippled, it's those who are too hardheaded to learn comething else that's crippled.
slashdot troll = you make a compelling argument I do not like the implications of.
On Unix you use a compiler and source code control, and it's great. On Windows you use just a compiler, and you call it crippled.
How about adding source code control, then at least you're comparing like with like. Or remove source code control from the Unix environment and then let's call that crippled.
Let's not just call it crippled because it's Windows please. As you say, lots of people are developing lots of software on Windows and it's a very mature platform for this sort of work, and everything is in place, but you have to get your finger out of your arse and configure it.
try http://www.mingw.org/
it's a version of gcc that builds native windows code. and it cross-compiles from linux if you'd like.
US Citizen living abroad? Register to vote!
I have to agree with you.
I've been avoiding SVN thus far because most folks are still using CVS, but SVN is pretty much an overall improvement over CVS -- even the CVS developers don't seem to argue too much.
* CVS has a very, *very* poor design from a security point of view. I admit that I'm not very familiar with the details of SVN's implementation, but with SVN, you can have an actual dedicated server that can filter what's coming in. With CVS, all you're doing is slapping a front end on SSHing in and running CVS as a program. It is extremely difficult, due to the *IX permissions scheme and CVS bugs relating to symlinks, to have a CVS repository that allows some users with access to a system, no access, some users read-only access, and some users write access but not administrative access. It is very easy to falsify CVS history -- it cannot be trusted to accurately log what a malicious user has done.
* CVS does not handle binary files efficiently (and doesn't really attempt to do so).
* CVS is annoying to set up/administer -- you pretty much have to hand out full shell accounts to users. I still think that it's kind of depressing to see administrators plea with users not to use high compression levels -- a VC system should just let you cap compression.
May we never see th
My first thought on reading the OP was "If they don't have the expertise to port a small build environment they built themselves, in-house to Windows then why do they think they have a hope in hell of porting their application?"
I have some trivial build scripts (bash) that check out a copy of the current source tree from the central CVS repository over ssh, setup a clean build environment, build the application (using a mix of qmake+make and cons) and run some basic regression tests.
I'm using the same scripts on Solaris, Linux, FreeBSD, MacOS X and Windows. On Windows they run under Cygwin, elsewhere under bash. There's some conditional stuff in the qmake files and the Construct files that sets compilers and commandline flags correctly (using Forte on Solaris, cl.exe from Visual C++ on Windows and gcc everywhere else).
It all works fine under cygwin. It took a little tweaking with environment variables to make everything happy (Cygwin + VC++ needs some configuration), but took less than a day to get running cleanly.
Combined with a central bash script that spawns a build on each machine (via ssh), takes the built and packaged result and uploads it to the distribution server it means I can release a build of all five architectures I support from a single source tree with a single command. I'm not using multiple machines for each architectures build farm, but that could be plugged in using distcc on some architectures fairly easily.
Invest a little time in making your build environment platform agnostic and it'll all run nicely. Unless money is very tight use a commercial compiler on Windows - Visual C++, Intel, maybe Borland - the quality of code generated is somewhat better than cygwin/gcc or mingw, the compile times are vastly better, and the pain in getting it to work well in a production environment a lot lower - due to the better "impedance match" between the compiler and the win32 tools. You'll only get the full advantages if you also use a cross-platform development library too - I use Qt, but wxWindows is pretty good for the cheapskates.
My actual development environment is emacs, bash and make/nmake. It's identical on Windows and the unixen. The fastest build environment is VC++ on Windows (due to better pre-compiled header support and a native compiler). The best for debugging varies depending on what I'm doing (Linux has valgrind and friends. Solaris has the Forte debugger which integrates with emacs very nicely). The same environment is installed on my PowerBook, so I can take the code offsite too, as long as I have occasional ssh access to the CVS server. As I'm building from a single source tree I can do 98%+ of the work on whichever platform is more comfortable and only very rarely have to worry about building debugging on a specific platform. QA is another matter, of course, but again the vast majority of bugs are in the platform independent code.
For C/C++ coding... If I was doing windows-only coding I'd strongly consider using Visual Studio, with embedded Emacs and some CVS (or revisions control system-du-jour). If I were doing Linux+Solaris-only coding I'd almost certainly use Vesta and either emacs or, perhaps, eclipse. For Mac-only XCode or, perhaps, eclipse would be the way to go.
But I don't foresee myself ever working on a single platform application again. And if I'm using native code (as opposed to, say, tcl or perl or python or even something that compiles to a JVM) I'll use the best system that runs cleanly on all those platforms. Right now that's emacs, Qt, perl+cons and a commandline compiler, IMO. And it scales fairly nicely if you have a decent source control system - CVS isn't that decent, but it works for small teams. For bigger teams I think you need a dedicated build engineer to handle source control and release anyway, but that's a whole other story.
There are some resources on the Microsoft site that may be of interest to you. Make sure no spaces were inserted into the urls.
/ en -us/dnucmg/html/ucmglp.asp?frame=true
p
On the Microsoft Developers Network:
The "Unix Application Migration Guide" can be read online and is available as a PDF.
The guide is about 2 years old, but it is the result of many consultants refining the process.
http://msdn.microsoft.com/library/?url=/library
Chapter 1 Introduction
Chapter 2 UNIX and Windows Compared
Chapter 3 The Migration process
Chapter 4 Assessment and Analysis
Chapter 5 Planning the Migration
Chapter 6 UNIX and Windows Interoperability
Chapter 7 Creating the Development Environment
Chapter 8 Preparing for Migration
Chapter 9 Win32 Code Conversion
Chapter 10 Interix Code Conversion
Chapter 11 Migrating the User Interface
Chapter 12 Testing and Quality Assurance
Chapter 13 Creating the Live Environment
Chapter 14 Migrating Fortran
Chapter 15 Roadmap for Future Migrations
On Microsoft Technet:
Windows Services for UNIX provides an environment to integrate your Windows machines into your UNIX environment.
http://www.microsoft.com/windows/sfu/default.as
I hope this stuff is helpful.