Well, to put my two cents in on this.... one of the reasons my organization didn't move forward from 3.x to 4.x in the first place was the short period of time when it was easy to perceive that the AOLServer community wasn't interested in Windows builds at all. That was a misperception, but it was a critically timed one (we'd just replaced the entire development team).
We do our 3.4.x builds using Visual Studio 2003 and have long hacked on the .vcproj files to get them to do what we need. It's often painful to remember that adding a new file to the build requires a fix to those files (or to the Unix side). And we can never keep the "debug" vs. "release" stuff straight; those files really are painful. We like to use the Microsoft compilers (and the VS suite) for a few reasons: * Our customers trust them. * Compiler diversity. Our modules are written in C++. We find it very useful to compile on at least three different vendors just to get their warning messages. To be honest, my organization could have given up on Solaris builds on the commercial side (nobody's bought it in years), but I keep those builds going (using the Sunsoft compilers) just for engineering quality checks. Getting stuck with just GCC would be a real problem on this front. * We like to use Microsoft DLLs when they're available for the job we're solving. For example, our crash dump libraries are written specifically to their debugger support library. * Debugging This goes to a part of the M$ development environment that's also useful: their debugging environment (even the free-as-in-beer windbg) sometimes proves better at finding the kinds of race conditions & locking problems we seem to write once a year and chase for months. It's certainly better at working with customer sites: we can usually verify whether a customer crash is a duplicate of something in our lab using their "minidumps", which will come in much smaller, since they only store stacks. I don't know if this sort of scheme is available in the MSYS world. (Of course, we do deal with the GB or bigger crashes in Linux -- and if the crash *isn't* a duplicate, we have to generate a full dump somewhere in Windows. The win is in being able to say "we know this one and we're on it" a lot faster). Just trying to provide insight; we haven't even downloaded an AOLServer 4 build in a year, and I don't know when we'll be able to try it. -- ReC -----Original Message----- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Piskorski Sent: Sunday, July 02, 2006 1:48 PM To: [email protected] Subject: Re: [AOLSERVER] Unix vs. Windows build environments On Fri, Jun 30, 2006 at 09:52:16AM -0400, Rick Gutleber wrote: > I do know that VC++ 2003 was, at least at the time, one of the best > compilers in the Windows platform (except for maybe Intel's), and > definitely the most standards-compliant. Yes, from Microsoft. Then that's yet another good reason to try to retain VC++ support for AOLserver, if feasible. > Of course, there's always gcc, right? I think providing a MS project > file is highly desirable (VS6 is still widely used despite being as old > Windows98 and newer versions of VS can handle .dsw/.dsp files), but On that bit I disagree. I've used those VC++ 6.0 project files, and they really suck. They are better than nothing at all, but that's about it. I don't think VC++ 6.0 project files do a good job serving the needs of ANY AOLserver user. No matter who you are, one or more other solutions would be a lot better - if they're supported by the AOLserver community. I assert that all people who have any desire to compile AOLserver on MS Windows fall into at least one of these three categories: 1. I don't want to compile anything, I just want to use stock AOLserver and all its modules on MS Windows, but compiling them myself seems to be the only way I can do that! Ugh, I hate this, but I am persistent, maybe I can figure it out... 2. I'm building stock AOLserver on MS Windows so Guy #1 above can use it. Hm, these build tools look pretty ugly. Maybe I'll hack something else together for my own use, but it'll probably never make it back into the official AOLserver build process. 3. I am doing custom development using AOLserver, either just on Windows or cross-platform, and both Unix and Windows. Most of my C code is in my own custom AOLserver modules, but I need to be able to patch the core code if necessary too. I MUST be able to build all of AOLserver from scratch myself, using tools I am happy with. Guy #1 above just wants working AOLserver binaries, all modules, all versions, automatically built, easily installed, ready to go. AKA, at least as far as the C code goes, he is a customer, not a developer. He doesn't much care what the build tools are, as long as they work out of the box, for everything. Guy #2 would mostly be happy with anything Guy #3 below is happy with, perhaps biased more towards simplicity rather than flexibility and power. However, he does not want to buy any Microsoft compilers or GUIs that he doesn't already own, not just for this. Guy #3 does NOT want ancient kludgy VC++ 6.0 project files. He might be more or less willing to deal with them if they're the only option, but in no case does he really want them. I think Guy #3 comes in two major flavors, let's call these Guy #3u and #3w: Guy #3u is a Unix geek crossing over to Windows. He wants some GOOD programmtic build evironment. Although far from ideal, configure and make would be ok, *if* they actually work on Windows. Using a zero cost compiler is often pretty important, and Microsoft's compiler is preferred because that's the compiler everyone else on Windows seems to use. He MIGHT be willing to buy and use Microsoft's GUI build tools if that route is already supported, and if using them isn't awful; then again, he might not. Guy #3w is a Windows geek (but one who is interested in using AOLserver, remember). He'd probably prefer whatever Microsoft's default GUI-ish build environment is in their latest VC++ 2003 or 2005 compiler toolkits. However, he'd also be happy with whatever Guy #3u above is happy with, AS LONG as it isn't a totally baroque Cygwin-like toolkit. Microsoft compiler is VERY highly desired. He MIGHT be willing to use gcc, Mysys, configure, and make on Windows, just barely; then again, he might not. (Configure and make are fairly ugly even on Unix, using using them on Windows can only make them more so.) I've pulled the above scenarios out of the air, and have absolutely zero scientific evidence that they're accurate. I suspect though that they do have some truth to them. I myself fit the Guy #3u profile above. I am no Windows geek, so the #3w profile is particularly vague and built from guesswork. Perhaps Jamie R. or others could correct or clarify it. :) -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
