CVS Windows build with gcc 3.2.3 from MinGW 3.1.0 works!!!

[Conrad T. Pino]

Hi Derek,
======================
<sarcasm>
Don't you just *love* Microsoft and their *wonderful*
development tools?  So full of *features* too!!!
</sarcasm>
======================
I have GREAT news.  MinGW looks extremely promising!!!
I was very annoyed with VC6 last night so I took a stab
in the dark and now have a working MinGW Windows build.

The number of patched files needed to get a compile to
complete is only two (2) files:

        lib/system.h
        windows-NT/config.h

I patched "lib/system.h" because it's larger compared
to "diff/system.h" and ordered -I options to place
"lib" before "diff".  Patching is needed because the
MinGW <sys/stat.h> contains *some* #defines but not
all expected by "system.h" which structures it's
#ifndef test expecting *all* or *nothing* and it
stumbles with the *some* case.

The "windows-NT/config.h" "typedef int ssize_t;"
which conflicts with gcc which uses a "long" rather
than an "int".  A surrounding #ifndef __GNUC__ does
very nicely.

The "cvs.exe" I compiled depends ONLY on .DLL files
all found in the Windows system32 directory.
------------
Installing MinGW is trivial.  The download is an EXE
file InstallShield application.

The default install point is "C:\MinGW".  Installing
to "C:\Program Files\MinGW" also works.

The InstallShield modifies the registry to provide
"Add/Remove Programs" support in "Control Panel"
and no more.  Very clean install and remove.

Using the Just In Time debugger requires installing
the supplied .reg registry file.  Not so clean but
trivial to manage nevertheless.

Add the "...\MinGW\bin" directory to the PATH and
it's ready to use.

MinGW package includes "mingw32-make.exe" which is
a subset of standard GNU make since the typical GNU
utils aren't part of this lean and mean package.
The Makefile hacks I used are based on this.

Copying the "...\MinGW" directory from one system
to another without using InstallShield works as
well after setting the PATH as said above.
======================
Now the not so good news:
------------
The MinGW package doesn't support automake, *nix
style configure, full GNU make.  This level of
support is available in an optional MSYS package
which provides *nix support somewhere between MinGW
and CygWin.
------------
I'm sure the "cvs.exe" I created is broken because
my Makefiles are hand created based on .dsp files.

Since I couldn't run "configure" using MinGW alone,
I'm sure I made all kinds of *bad* choices with
respect to -D options and who knows what else.
------------
I'm close to the end of what I can do to bring this
idea to full fruition.  I think I can do more with
some mentoring which is part of the reason why I'm
publishing a preliminary report now.
======================
Path forward options follow:
------------
Choice 1: Build file management.

Option 1A: Manage build with configure script
using MinGW MSYS package.  This says it so much
better than I: http://www.mingw.org/msys.shtml

Option 1B: Manage build with IDE project manager
like MinIDE http://www.spacejack.org/minide/ and
there are others.  Search for "MinGW" on this page
http://www.spacejack.org/games/mingw/.

IMO Option 1A promises using the same configure
script and same Makefile.am for *nix & Windows.
Option 1A looks out of my reach at this point.

I'd like some input from CVS project before
committing a lot of time to the wrong path.
------------
Choice 2: Adopt MinGW support or not.

Option 2A: Adopt MinGW *and* keep VC support.

Option 2B: Adopt MinGW then *drop* VC support.

Option 2C: Stay with VC for now and work on
other things with greater value than having
a gcc Windows compiler.

Option 2D: Solicit help developing MinGW
support from other projects.

I'd like some input from CVS project before
committing a lot of time to the wrong path.
------------
Choice 3: Soliciting MinGW help.

I'm considering raising this topic on the
MinGW and CVSNT lists since IMO there may
be a considerable interest overlap.

I'd like some input from CVS project before
setting off unintended consequences.
------------
Choice 4: Publish my MinGW build hacks.

I'm considering publishing my Makefile hacks
and patches to create interest in this topic.

I'd like some input from CVS project before
setting off unintended consequences.
======================
I'm setting this topic aside in order to focus on
other tasks I've started.

I'm flexible about what I contribute.  My only
concern is contributing *real* value rather than
what I imagine has value.

If there's no interest in this topic, I plan to
let it die.

If anyone wants to discuss, please email to make
a phone call appointment.
======================
Best regards,

Conrad Pino