RE: autoconf in pure MSVC environment?

[Brandon J. Van Every]

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