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
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.
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.
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.
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.