Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Operating Systems Software Windows IT Technology

Scalable Windows Development Environments? 63

Posted by Cliff 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."
This discussion has been archived. No new comments can be posted.

Scalable Windows Development Environments? More

Scalable Windows Development Environments?

Comments Filter:

  • Try Borland (Score:4, Informative)

    by samjam ( 256347 ) on Saturday October 09, 2004 @03:58PM (#10480844) Homepage Journal
    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

  • TortoiseCVS (Score:3, Interesting)

    by truz24 ( 800762 ) on Saturday October 09, 2004 @04:02PM (#10480870)
    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/)

  • Cross compile! (Score:4, Interesting)

    by Jepler ( 6801 ) <jepler@unpythonic.net> on Saturday October 09, 2004 @04:04PM (#10480884) Homepage
    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.

    • Re:Cross compile! (Score:1, Insightful)

      by Anonymous Coward
      As a person who has been programming on Unix since 1992 and linux since 1998, and has been in charge of CVS and general development environments at 3 companies across many different platforms, let me say that the environment you describe comes very close to "the horror that is Windows development".

      Write real makefiles, and get out of RCS and into CVS. Install GNU make and WinCVS on your windows machines, and do the builds there, invoke the MS compiler from the command line (or using gcc or MinGW). Or do

      • Write real makefiles

        Actually, I love our makefiles. We are using GNU make. It's a non-recursive build, so every time you invoke "make", you know the results are right.

        get out of RCS and into CVS

        While it sounds tempting, there's really no use for CVS in our shop. There are no off-site developers (so no need for cvs-over-ssh or the like), and the makefile-supported "workarea" concept is a better way for us to allow each developer to have independent changes. [see below]

        [...] and do the builds th

    • It's a development team. They will be wanting to debug things. Cross compiling is a somewhat crippled way of doing things if you want to debug.

      My team use Borland Delphi. We have 250,000 lines of code. The entire build takes 15 seconds on my old P3 700. It's much less on our lovely Opteron. Thus code, run, debug, code cycles happen very quickly.

      If you want to avoid crippled environments how about getting away from a multi-pass language! The problem being discussed here is actually the problem of ex

  • Not sure I understand your problem (Score:4, Interesting)

    by Screaming Lunatic ( 526975 ) on Saturday October 09, 2004 @04:05PM (#10480894) Homepage
    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?

    • What exactly are you having problems with?

      We were able to port our Unix development environment to Windows, through Cygwin, but it is totally unworkable and so we scrapped it (on Windows).

      Currently we are just using Visual Studio with the whole repository checked out. The problem comes when you edit. All of us are vi or emacs junkies and find the VisStudio editor to be, well, infantile. That's part of the problem. The inefficiencies that are created by editing outside of the IDE are a problem.

      I guess th

  • Simple Answer (Score:1, Flamebait)

    by Rie Beam ( 632299 )
    "What are Slashdot users, who must develop under Windows, using for a development environment?"

    Knoppix?
  • Subject says it all.

    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.

  • Borland Development Environment (Score:3, Interesting)

    by Ronin Developer ( 67677 ) on Saturday October 09, 2004 @04:55PM (#10481195)
    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.

  • CVS replacement (Score:3, Informative)

    by bobbozzo ( 622815 ) on Saturday October 09, 2004 @05:08PM (#10481277)
    Subversion [tigris.org] is a good replacement for CVS, and works on UN*X, OSX, and Windows (w/ command-line and explorer shell extensions).
    • What about the build system?
      Looking around, make has the entrenchment of CVS, and you can go MinGW, but then there is the licensing.
      Boost.Jam looks like it could be a ticket to ride, and is almost required to do Boost.Python, but the documentation isn't quite there yet.
      What do people think of SCons? How can Python be wrong?
      • We found SCons to be very slow - we're talking 2-3 minutes of churning for it to decide that everything is up-to-date. Boost.Jam on the same set of files is around 5-10 secs.

  • Developing on Windows, Unix style. (Score:5, Informative)

    by Anonymous Coward on Saturday October 09, 2004 @05:44PM (#10481489)
    Let's see. We need a compiler:
    C:\>cl
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
    Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

    usage: cl [ option... ] filename... [ /link linkoption... ]
    Wow! That was tricky. Next we need a version control system. I don't like CVS (even though I know a Windows version is available), so let's try something a bit more modern:
    C:\>svn
    Type 'svn help' for usage.
    Holy cow! We have a version control system installed.

    Now.. build system. How about something modern, cross-platform, that used Python scripts to control the build process...
    C:\>scons

    scons: *** No SConstruct file found.
    File "c:\python23\scons\SCons\Script\__init__.py", line 794, in _main
    Sweet! I guess I'm all set then! Here's how you can get all of the above - for free:

    * Scons [scons.org] build system (requires Python [python.org] to be installed first).
    * Subversion [tigris.org] (SVN) version control system.
    * Visual C++ 2003 Optimizing Compiler [microsoft.com] with the Windows Platform SDK [microsoft.com].
    * Microsoft Developer Network [microsoft.com] - free documentation and API reference (although this should be included in the platform SDK above).
    * TortoiseSVN [tigris.org] - 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 [sourceforge.net] 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 [python.org] 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 .vcproj file so they can be edited independantly of the rest of the project. The sections are then brought together through a single solution (.sln).

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

      Examples, please...?
      • The class wizard gets very unhappy if you add functions with telling it. It is possible if you spend the time to learn all the little comments it wants to embed with your code but it is very painful.

        Apps written in this way tend to end up with pretty much all of the code in a FooDoc.cpp or FooView.cpp since it is generally easier to let the class wizard have its way than fight against it.
  • 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 [scons.org] or CMake [cmake.org] 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).
    • 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
    • I have not used CMake, but I considered CMake vs Scons when needing a cross-platform build environment (Windows and UNIX, since autoconf/... is cross-platform enough for UNIXes). CMake integrated better than scons into the MS Visual Studio by creating a native project/solution file. However, the cmake templates themselves seemed harder and since I already key some python, I chose scons in the end.

  • So let me get this straight... (Score:3, Insightful)

    by jazman ( 9111 ) on Saturday October 09, 2004 @07:37PM (#10482286)
    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'll say amen to that. Just because the
      system doesn't come equipped with all the goodies,
      doesn't mean that the tools aren't just a
      download away.

      Having done a fair bit of Unix programming, I'd
      say nothing comes close to MSVC for speed
      and ease of use (browsing references, etc)

      steve d.

  • mingw (Score:4, Informative)

    by kevin lyda ( 4803 ) * on Saturday October 09, 2004 @07:56PM (#10482416) Homepage
    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.

    • Re:mingw (Score:1, Interesting)

      by Anonymous Coward
      It cross-compiles from cygwin too, just pass -mno-cygwin to gcc.
  • I guess the headline says most of it. Where I work we use VS.NET, WinCVS and a CVS Server running on a nix enviro. Works fine. Once in a while when you merge a project file you will get conflicts, which means you have to go in a fix it manually. It is in a readable XML format so after a few minutes work you are fine. Conflicts in other files happen just like they happen to files under CVS source contol in unix.

    If you have a really big project, I would really recommend breaking it up into sub-projects

  • 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.
    • Would an editor that crashes from time to time really be something to recommend to a software company? I've used Dev-C++ for testing code I write to make sure it will compile and run in Windows, so I don't actually use it for much editing. But if I did, and it crashed, I'd switch up fast. I just use it for it's easy project/build system.

      Dev-C++ looks great for those who want to develop on Windows but don't want to buy MS Visual Studio, and it gets the job done for me, but if it does crash on typical uses,
  • 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 [cygwin.com] is for that.
    • Silly post, flames are for kids...

      Unix is designed for development.
      The original UNIX was designed as a document processing system. Development is just a means, not an end. OSes are used to run apps. Windows, whether or not you like it, has a set of tools failry well designed to get people coding quickly. The back end APIs are a bit icky at times though.

      Secondly, it would be a very rare and odd thing for your unix code not to be easily portable to the Windows environment.
      Whether it's portable does
  • http://ant.apache.org/ [apache.org]

    It's not just for Java.

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

    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 ha
  • I use my bash shell, vim and GNU make on windows as well. See Cygwin [cygwin.com] and Vim.org [vim.org]

    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.

  • Bash + CVS + ssh + perl + cons + Visual C++ (Score:3, Informative)

    by SSpade ( 549608 ) on Sunday October 10, 2004 @12:22PM (#10486305) Homepage

    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 [vestasys.org] 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 did in fact port our build platform to cygwin, but it was painfully slow because of the way cygwin handles file system translation. (e.g. "/usr/local/" has to be mapped to "C:\xxx\" everytime to access a file. When you access many many files this becomes very very slow. This is what makes our build system unusable under windows.

      You have not found your scripts to slow down under cygwin? How many files are in your project, are they all in the same directory? I believe our project may suffer from slight di
  • 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 plu

  • Microsoft Resources (Score:2, Informative)

    by DittoHead ( 214129 )
    There are some resources on the Microsoft site that may be of interest to you. Make sure no spaces were inserted into the urls.

    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 / en -us/dnucmg/html/ucmglp.asp?frame=true

    Chapter 1 Introduction
    Chapter 2 UNIX and Windows Compared
    Chapter 3 Th

  • Completely free and open-source... (Score:1, Informative)

    by Anonymous Coward
    Well, we have an automated build system that is, with the exception of SourceSafe, completely free.

    The .NET Framework SDK 1.1 [microsoft.com] providers all the compilers, resource generators, etc. Completely free from MS.

    We use SourceSafe for version control. Though there are free alternatives out there.

    We use Draco.NET [sourceforge.net] to fire off builds automatically, and to give reports of the builds via an XML file and e-mail.

    We use NAnt [sourceforge.net]for build workflow. As well as the version and record tasks from NAntContrib [sourceforge.net].

    We use VB.Doc [sourceforge.net]
  • 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.

Slashdot Top Deals

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Close