Another step towards easier support for multiple Windows compilers (such as reintroduction of Watcom support) would be to use a single Makefile. It really sucks that adding a new object file requires changing src/Makefile.in and *three* different Windows Makefiles.
To simplify the infrastructure, I suggest the following: 1. Require GNU make for building. This refers only to the actual `make' binary -- other Unixy stuff such as sh, grep, sed, would *not* be required (except under Cygwin). The benefit is that there would be only one Makefile, only one list of object files, only one syntax, etc. 2. Get rid of top-level Windows Makefiles. The src directory is the only one that really matters anyway, and configure.bat can easily instruct the user to cd to "src" before typing `make'. The benefit is that we'd get rid of the ugly Makefile.top vs. Makefile.src distinction, especially as Makefile.top doesn't really buy us any functionality. 3. Add the redundant #ifdefs to all compilation-dependent C files to make sure that they are ignored when the libraries they require are missing. For example, openssl.c should be wrapped in #ifdef HAVE_OPENSSL. That way the Windows-specific Makefile could contain a static list of object files and not require a "configure"-like infrastructure for rewriting it. 4. Create a generic windows/Makefile which allows GNU make to compile and link Wget on Windows, assuming that compiler-specific variables would be given elsewhere. Things like new object files would be done here. 5. Create windows/Makefile-$compiler for each $compiler we support, which contains the necessary CFLAGS, LDFLAGS, etc. configure.bat --$compiler would copy both windows/Makefile and windows/Makefile-$compiler to src. The overall benefit of this layout would be that making changes to the source without breaking Windows builds would become much easier, even for people without regular access to a Windows compiler. Additionally, adding a new compiler would only require a new Makefile-$compiler and a new section in config-compiler.h. Then we could support a very large number of Windows compilers without it ever being a problem.
