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?
"...and I can't imagine that everyone has a crippled development environment...
Most windows developers have never used, do not know how to use and might not even know anything about *nix. They do not realize how crippled their development environments are because they have never used anything else. They often weigh the easiness of clicking as more valuable than the power of a nice build script that you would have to write.
In other words, the vast majority of windows build environments are extremely crippled. But the people using them either suck it up or don't know any better. Try mingw, a little better than cygwin.
The GeekNights podcast is going strong. Listen!
"What are Slashdot users, who must develop under Windows, using for a development environment?"
Knoppix?
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.
This is actually a very good idea. The first lesson should teach people how to ditch outlook, clean the viruses and spyware out of their computer, and install thunderbird and firefox. The second lesson should teach them how to backup their mail and bookmarks to a cdrom or other harddisk, and (often overlooked) how to recover them. The third lesson should teach them how to install linux.
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.
A hammer.
Applied directly to the base of my manager's skull.
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
Without changing development methods, you could probably use Trolltech's QT. The licence under windows is not Free, but it's not more expensive than visual studio. It generates native interfaces and the API is quite well designed. It's really meant to be cross platform. Actually, it looks a bit like Java.
I havn't developped under windows for a while. I just can't stand it. The best solution is probably to keep using CVS or switch to Subversion. I would avoid visual studio. It generates a lot of code but it's all unreadable and from the moment you edit it manually, the application simply fails to understand it.
Actually, I also have been wondering how developpers could be efficient under windows for a while. I never found an answer.
Qui ne va pas à la chasse n'a pas de gibier
PHP Queb
If you are also considering hacing at least part of the code work on both Windows and UNIX, having CVS or Subresion for source control and Scons or CMake for build control might help. Where I work we develop on windows, Linux and Solaris and we are using CVS & scons (scons/python seemed better than learning to use the cmake scripting language).
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.
I started looking at cmake (despite the name, a replacement for autotools, not for make) just two days ago and so far I'm definitely interested. I've been very frusterated with GNU autotools (automake, autoconf, etc) for a long time. While they *do* perform their tasks, they are very difficult to learn. It is difficult to debug autotools problems -- most of the autotools-using projects I've seen have had scripts written at least somewhat incorrectly. Backwards and forwards compatibility in autotools has traditionally been very poor. It often takes quite a bit of code to perform fairly common tasks.
Cmake seems, at least on the surface, to solve a number of these problems. It also seems to be easier to do cross-platform-with-Windows development with.
So, has anyone out there used Cmake much, and if so, what do you think?
May we never see th
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!
If you have a really big project, I would really recommend breaking it up into sub-projects that compile into various DLL files, and use one big solution file to hold all of these in Visual Studio. IN VS.NET the name of the "big" project file is called a "solution", which holds a bunch of "project" files. In Visual Studio 6, I believe the "big" project file was called a "project group", but is has been a while. Whatever the name, you you can group the functional areas of a large project into smaller, more manageable units. Not only does this make applying patches, etc, easier to test environments, but CVS merges will cause conflicts less often in the various project files.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
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
I use Dev-C++ for much of my Windows C/C++ develop. It's good enough but not awesome, crashes or pauses from time to time while typing. I also have VC++ 6 and VS.NET.
Firstly, it seems very odd to be moving development from unix to windows. Unix is designed for development. Windows is not. I would seriously take a look at your reasons for doing this.
Secondly, it would be a very rare and odd thing for your unix code not to be easily portable to the Windows environment. Cygwin is for that.
-I like my women like I like my tea: green-
http://ant.apache.org/
It's not just for Java.
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
We use Accurev for our source control - the GUI is a little rough around the edges but the source control system scales brilliantly - it is definately worth checking out. It isn't free though.
.vcproj files that you can use with .NET since most of our developers work within that and like being able to use the code browser and stuff like that. Compilation is still all controlled by Jam though.
.NET project files just wasn't feasible for us, especially since we need to compile for several different platforms.
Prior to that we were using CVS for source control under windows with no problems. The CVS server was hosted on a Linux machine - but then so is our Accurev server.
As for build systems, we were using cygwin/make with no real issues but have since switched over to Boost.Jam which has proved really successful. We have some rules that general
We used SCons for a while, but found it to be incredibly slow for big projects. This was about a year ago now so this may have been improved.
With Jam and SCons though, just like with make, you'll need to spend quite a bit of effort getting your build system setup. The results are well worth it - maintaining lots of
Also, if you want to do GUI stuff I can't recommend Qt enough. I suppose MFC works, but I find it really alien, especially if you're used to more Unixy style development.
For VIM I use the Project plugin, which gives me just enough IDE like stuff.
The M$ C compiler runs fine from command line, you dont have to use the Visual Studio.
Works very fine for me.
I had this same problem earlier this year. I found it to hard to do the build process of unix apps under windows so I used a cross compiler and just modified all my build scripts under linux. I used mingw32 and downloaded all the relivant win32 libraries + headers that i needed.
Using a couple of scripts I download from the cvs server the latest version of my code then use modified makefiles to build. I then have a batch script to copy the binaries over to windows from linux. I can do the build from the linux server though ssh and then have another script under windows for copying the result to windows for testing.
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.
We run .NET from the command line for dailies, and use python scripts to copy built stuff to QA servers (and send error and warning summaries to the whole team.
.NET is rancorous, until tamed with a few user-generated commands; I've added tools to do common Perforce tasks (diff, revert, and my favorite, "Where's the #@$(@ing file?!", which opens an Explorer window containing the file being edited.
r vi ew.php>
Perforce is sublime. Five stars, kudo's, and I'd buy their developers beer if they lived closer. Oh yeah, each build's release notes are auto-generated by the Perforce build label, which mines the bug and feature DBs (FileMaker; I know, deride away, but hey, we only do Mac & Windows) for check-ins that happened since the last build, sorted by functional area.
We also use Code Historian for badass multi-version diffing, and to find long-term hotspots that need to be re-engineered.
<http://www.codehistorian.com/codehistorian-ove
Like many others, I don't see what the problem is moving from unix (with its arcane editors ;-) to windows.
To put that into perspective, you probably are comfortable with your unix environment because you learned to use it, and then to customize it.
You complain about syncing files in visual studio. Without a more specific problem, I can only say this: that is what visual studio is good at! Why? Because MS created a standard way for versioning systems and editors to communicate. A versioning system can plug itself into anything that uses this (it's called the SCC API). So get an SCC plugin for Visual studio for the versioning system you like. To show you just one, here is a CVS one: http://www.pushok.com/soft_cvs_proxy.php
If you need to do things that aren't present or easy in the SCC plugin, put up an 'external tool' in Visual studio, and assign a shortcut key. Use CVS' command line tool to pass the options you need.
Or let us know what problems you have exactly.
Also, what are you using on unix? Why aren't you using just that on Windows? Windows has a command prompt, and most things you'd need (like cvs) are controllable from it like you'd do on a unix machine, I think. And e.g. an emacs port shouldn't be hard to find, if that is your thing. What are you missing?
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.
Well, we have an automated build system that is, with the exception of SourceSafe, completely free.
.NET Framework SDK 1.1 providers all the compilers, resource generators, etc. Completely free from MS.
The
We use SourceSafe for version control. Though there are free alternatives out there.
We use Draco.NET to fire off builds automatically, and to give reports of the builds via an XML file and e-mail.
We use NAnt for build workflow. As well as the version and record tasks from NAntContrib.
We use VB.Doc to rip XML comments out of any VB code, and NDoc to take all the XML comments and create MSDN-style developer documentation.
We use NUnit for our automated unit testing. We currently use NUnit2Report to make the XML test case results into pretty reports, but we might just write a utility to combine all the documents ourself and just use XSL to do the transforms.
Last, we use InstallShield to create installer projects, but you could use Wix or something else to make them for free.
The first lesson should learn every moron to post ontopic.
There are plug-ins available for VS that support cvs and subversion (ankhsvn, or something; it's on the svn site). You really shouldn't have issues with sharing files between developers. Look at TortiseCVS and TortiseSVN and WinCVS, etc., for more options.