Scalable Windows Development Environments? 63
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."
Try Borland (Score:4, Informative)
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)
Cross compile! (Score:4, Interesting)
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
Re:Cross compile! (Score:1, Insightful)
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
Re:Cross compile! (Score:1)
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.
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]
Re:Cross compile! (Score:1)
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)
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?
Re:Not sure I understand your problem (Score:2)
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
Re:quote (Score:1)
One of the things about open source is that having the source allows you to build things anywhere. Hence all the best open source development tools can be run on Windows.
If you want the usual *nix tools then just use them.
End of story.
Re:quote (Score:2, Informative)
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 windo
Re:quote (Score:1)
Re:quote (Score:2)
e.g. on *IX, I'd have a flag set in my Makefile for all, say, BSD variants only (which might be several "build configurations"), and I'd make one change. With VS, do I need to manually make the change for each BSD-variant build configuration?
Re:quote (Score:1)
But, I think what you are saying can be acomplished with the build manager. With it you can specify module to include or exlude, define different preprocessor vars etc. Essentially every change you make to the 'current' build environment can effect all builds or just the one you have currently selected. That is what I meant when I said pick nunit in a combo and build - nunit is a seperate
Re:quote (Score:2)
Is that what you are asking about?
Sort of. IIRC, there are "current build configuration" and "global build configuration" stuff, but c
Re:quote (Score:2)
Simple Answer (Score:1, Flamebait)
Knoppix?
Visual Studio/C#, Windows build tool, Source Depot (Score:3, Informative)
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)
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)
CVS/SVN benefits (Score:3, Informative)
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
Re:CVS replacement (Score:2)
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?
Re:CVS replacement (Score:2)
Developing on Windows, Unix style. (Score:5, Informative)
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 [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
Re:Developing on Windows, Unix style. (Score:1)
That's free as in beer, folks.
Re:Developing on Windows, Unix style. (Score:2)
To add to the list...
MinGW [mingw.org] - because you need a good CLI. (Alternatives include Cygwin [cygwin.com])
Vim [vim.org] - Better than emacs =)
Re:Developing on Windows, Unix style. (Score:2)
There are alternatives (Score:2)
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
Re:There are alternatives (Score:2)
Examples, please...?
Re:There are alternatives (Score:2)
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.
CVS/Subversion and Scons (Score:1)
Opinions on Cmake? (Score:2)
Re:CVS/Subversion and Scons (Score:1)
So let me get this straight... (Score:3, Insightful)
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.
Re:So let me get this straight... (Score:1)
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)
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)
Visual Studio + WinCVS + CVS Server Works Fine (Score:2)
If you have a really big project, I would really recommend breaking it up into sub-projects
Dev-C++ (Score:2)
Re:Dev-C++ (Score:1)
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,
You don't want to do that. (Score:1, Flamebait)
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.
Re:You don't want to do that. (Score:2)
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
Use Apache Ant (Score:2)
It's not just for Java.
Re:Use Apache Ant (Score:2)
Boost.Jam + Accurev (Score:2)
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
Use your tools (Score:1)
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)
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.
Re:Bash + CVS + ssh + perl + cons + Visual C++ (Score:2)
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
Just develop the unicx way if that is your style? (Score:1)
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)
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)
The
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]
Re:Completely free and open-source... (Score:2)
My condolences.
Repository plug-ins for Visual Studio (Score:1)