"Brandon J. Van Every" <vanevery@xxxxxxxxxxxxxxxxxxx> writes:
> 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.
But Windows /is/ a second class citizen.
The fact of the matter is that the baseline standards for software
development are: ISO C, ISO C++, and POSIX/SUSv3. They are all a
given (bar minor incompatibilities) on nearly every platform but
Windows. Windows /is/ the odd one out, being gratuitously
incompatible with everyone else. This imposes a heavy burden on
porting to Windows, so that people like myself who would like to build
Windows-native versions of our software have not the resources to do
so--despite supporting every other commonly available OS out there!
For people like me, targeting a Cygwin or MinGW toolchain isn't not
"being serious" about Windows support--it's the only choice. There
isn't an alternative toolchain available, and non-POSIX toolchains are
not supportable: the build infrastructure for many projects is
non-trivial (for gimp-print, the bootstrapped build infrastructure
totals over 65000 lines). The fact that there has never ever been a
standard build environment on Windows does not help matters. Can I
rewrite an entire build system for just /one/ platform? No, of course
not! The build took man months to write and especially debug, so it
would build on every other platform--that's being serious about
portability!
For many projects the entire development team uses Linux, UNIX and/or
MacOS X. Windows support will only be supportable if there are folks
using Windows daily who are willing to do the grunt work, since folks
like myself do not have the skills to debug Windows issues such as DLL
linking problems, or even normal bugs. Since we are not using Windows
regularly (if at all), while we are not against a Windows port, there
is not much we can do to make it happen either.
In March, I spent a significant amount of time building GTK+ 2.2.4 and
its dependent libraries for Cygwin. It took several weeks, basing my
work on previous patches for 2.2.1. I then had to forward port the
patches to GTK+ 2.4.x. Thankfully these were incorporated in the
official release [GTK+ is now part of Cygwin]. Once I had the build
and portability issues fixed, I could then build my software. It ran
reasonably well (using Gtkmm and Postgres). Building "native"
non-Cygwin versions would have been an order of magnitude more
difficult--well outside my capabilities.
The solution to this problem is for Microsoft to provide a full POSIX
environment (APIs and tools) which would greatly ease both porting and
native development. Having a working DLL implementation would also
help. This would however be nothing more than a reimplementation of
Cygwin. It's called "Windows Services for UNIX". If it came as
standard with the OS, it might even be useful.
I think you need to approach the question from the other side: it's
not a question of how the autotools must change to accommodate
Windows, it's a question of how Windows can provide a Standard POSIX
environment for building and running POSIX applications. When Windows
can provide such an environment, it will cease to be "second class"
(in this respect).
Regards,
Roger
--
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
