RE: autoconf in pure MSVC environment?

[Brandon J. Van Every]

A preamble, in the hope of conditioning further responses.  I think we
could go back and forth about cultural isses until the cows come home,
but I'd be more interested in focusing on the feasibility of the
problem, as stated in the subject line.

Bob Friesenhahn wrote:
> Brandon J. Van Every wrote:
> >
> > 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.
>
> Most package configure scripts only test for functions which are not
> reliably available across Unix systems.  They assume that baseline
> Unix/POSIX functionality exists.  This means that an inspection of an
> existing configure script will not indicate how difficult the
> associated package will be to port to Windows.

Interesting point I hadn't considered.  Nevertheless, a configure script
*does* march through a number of points of failure quickly.  For
instance, is Library X available on the system?  Ok, get that working.
Autoconf under pure MSVC doesn't have to solve everything.  It just has
to substantially reduce the amount of work required to evaluate the
portability of a project.

Also, I disagree that 'most packages' assume a baseline of Unix/POSIX
functionality.  The last 2 game projects I ported from Mingw to MSVC
were already quite platform neutral, there was little remaining to "put
them under the table," so to speak.  Even if you are correct regarding
statistics, it's not relevant.  What's relevant is the specific project
to be ported, not the general case.  Projects are self-selecting in this
way.  I'm not trying to port *everything* to MSVC, I'm trying to port
what's already fairly feasible to port.

> > To get real duplicability of build environment, and real
> > vetting by a
> > lot of Windows developers, code has to be built natively under MSVC.
>
> What version of MSVC? 6.0 != 7.0 != 7.1

Since you brought that up, VC7.1.  The plethora of VCs is a related
problem in open source development.  Many open source projects have made
it to the point of providing a VC6 build, but haven't moved on to what
native Windows developers consider a modern compiler.  Availability of
the compiler isn't the issue, as Microsoft provides the compiler sans
Visual Studio IDE for free:

http://msdn.microsoft.com/visualc/vctoolkit2003/

Rather, it's inertia, desire to support old libraries and tool chains,
amount of work of moving forwards, stacked library dependencies, lack of
volunteer energy or enthusiasm for Windows platform issues, etc.  Not
all pushes forwards in MSVC-land are bad, BTW.  C++ STL compliance
improved tremendously from VC6 to VC7.  Standard library is forced in
VC7.1, i.e. must switch from <iostream.h> to <iostream>.

> From this standpoint, a Windows build scheme based on the GNU Auto*
> tools is much more stable and not subject to "upgrade hell" since it
> depends on tools which have had their interfaces defined for the past
> 25 years.

But it is not mainstream reality.  I think one of the engineering
dimensions we all should be dealing with, is reality.  In practice, the
vast majority of the Windows world uses MSVC.  You can either see the
goal of open source as "toppling" Microsoft and all of these people, or
in terms of making it easier for people to do what they actually want to
do.  You won't get open source culture on Windows by insisting that it
has to become UNIX.

The past 25 years are also not the future.  In the OCaml community we've
got, like, 10 different projects trying to improve upon GNU Make and GNU
Autoconf.  The main advantages of Autoconf / Make are that they're
widespread, battle-tested, and familiar, not that they're ideal.

> Windows isn't a second class citizen? ;-)

Thanks for making my point.  There are at least 3 possible world views:

- UNIX is what matters
- Windows is what matters
- platform neutrality is what matters

I am of the "neutrality" camp.  I dislike all OSes, as they only get in
the way of game, 3D graphics, and AI problems.  When my back is put
against the wall, I will defend the "Windows" camp, because I'm trying
to develop commercial games.  Windows is the dominant market for that.
I'm stuck with that platform for the forseeable future.  I want as
little rigamarole to deal with my problems as possible.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie