John W. Eaton wrote: > > This is a serious question, Ok, because you have a serious *question*, and aren't just trying to change everyone's mind in Windows-land to engineer everything the way you're used to, I'll give you a serious answer. > When you say you remove the UNIX dependencies, do you mean that you > litter the code with > > #ifdef MSVC > ... > #else > ... > #endif > > or do you try to isolate and duplicate the functionality in a > compatibility library? Whatever is the best engineering solution, considering available time and complexity. > For clarity, it would seem better to introduce > some abstraction and use a compatibility library, I see no a priori reason for this. A priori, you don't know anything about the size of the project, how the code is organized, where the UNIXisms are, how many there are, what they can be replaced by, what systems they affect, or how much effort at making the code platform neutral is already underway. You might need some massive library, or you might need 3 #ifdefs. In fact, my idea about using Autoconf is to determine if the dependencies are so minor that they *can* in fact be dealt with trivially. > but then if you are > going to do that, then why not just use Cyginw? It may come as a surprise to some around here, but mainstream Windows developers have no interest in Cygwin. It is UNIX-oriented, and if you use its UNIX compatibility library, your project is now GPL. Mingw's licensing is fine, but it still UNIX-oriented and mainstream Windows developers do not want it. Cygwin / Mingw exist principally for the benefit of UNIXen who do not wish Windows to be Windows. They are Windows avoidance solutions, not Windows support solutions. In practice, the open source Cygwin / Mingw driven projects I've looked at compile badly on Windows. Often the developer culture is strongly UNIX-oriented, so most of the testing and vetting actually gets done on UNIX. Few are kicking it around on Windows. Even worse, often the app is cross-compiled from UNIX to Windows. I find it remarkable that this often works, but it also creates a development environment that a native Windows developer can't duplicate, short of becoming a UNIX developer herself. In a UNIX universe, particularly a Linux universe, libraries are nicely packaged up and play well together. These same UNIX libraries are never packaged up well on Windows, so the build environment can almost never be duplicated. Usually some UNIX guy just has his 'homebrew' Windows environment, that he hardly ever updates. "It works for him," it's good enough for generating *his* .exe's, and he doesn't care about whether anyone else can duplicate the build environment. To get real duplicability of build environment, and real vetting by a lot of Windows developers, code has to be built natively under MSVC. That's not an absolute, but it is the correct "in practice" operative statement most of the time. My rule of thumb is if a project is Cygwin / Mingw, they aren't serious about Windows support. Part of this is cultural, not just technical: they're UNIXen and Windows is viewed as a second class citizen. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA "Troll" - (n.) Anything you don't like. Usage: "He's just a troll." _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
