Slashdot Mirror

← Back to Stories (view on slashdot.org)

Scalable Windows Development Environments?

Posted by Cliff on from the what-makes-you-confortable-when-coding dept.

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

5 of 63 comments (clear)

  1. TortoiseCVS by truz24 · · Score: 3, Interesting

    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/)

  2. Cross compile! by Jepler · · Score: 4, Interesting

    My day job is a large C++/tcl application with thousands of source files. We build for Unix and for 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 .EXE file using Open Source software on Unix. And get some other poor fellow to do the testing on Windows.

  3. Not sure I understand your problem by Screaming+Lunatic · · Score: 3, Interesting
    Is it just porting the build scripts that you're having problems with?

    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?

  4. Borland Development Environment by Ronin+Developer · · Score: 2, Interesting

    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.

  5. Re:mingw by Anonymous Coward · · Score: 1, Interesting

    It cross-compiles from cygwin too, just pass -mno-cygwin to gcc.