An alternative build system with excellent Windows (and Unix) support would be cmake.
http://www.cmake.orgCMake is used by the KDE project, as well as LyX, and many others. It is much faster than autoconf+friends, much easier to understand, and has broader platform support.
However, having a hand-made config.h for Windows is hardly a big
problem, since as far as I can tell, config.h would be pretty static on
Windows.
**
In my efforts to compile Gnash on Windows, I've encountered a file which need to #include "tu_types.h": amf.cpp.
snprintf is sometimes #define snprintf _snprintf, but why not put this in
config.h?
rint is used in character.cpp and sprite_instance.cpp, and round in sprite_instance.cpp. Maybe those uses can be replaced with floor or ceil which should be portable?
Also, strcasecmp is used directly in sprite_instance.cpp. I assume this should have been STRCASECMP, as defined in
container.h.
Sometimes, #include <unistd.h> is guarded like this:
#if !defined(_WIN32) && !defined(WIN32)
# include <unistd.h>
#endif
but other times, it's not. I guess all places should be updated. Alternatively, an empty unistd.h file could be put in win32/vc8.
These look like a genuine errors:
tu_file_SDL.cpp
..\..\libbase\tu_file_SDL.cpp(111) : error C2065: 'm_error' : undeclared identifier
shape.cpp
..\..\server\shape.cpp(644) : error C2326: 'void gnash::mesh_set::{ctor}::collect_traps::accept_trapezoid(int,const gnash::tesselate::trapezoid &)' : function cannot access 'gnash::operator =='
xml.cpp
..\..\server\asobj\xml.cpp(160) : error C2440: '<function-style-cast>' : cannot convert from 'double' to 'gnash::XML::Status'
Conversions between enumeration and floating point values are no longer allowed
backend\render_handler_tri.cpp(347) : error C4716: 'gnash::triangulating_render_handler::world_to_pixel' : must return a value
In date.cpp, there is an #include <sys/time.h>, which I guess only exists in Mingw. If this is the only reference that needs Mingw headers, maybe it's better to just reimplement the needed functionality using Win32 API directly instead?
With these changes, I'm down to problems due to missing dependencies, which I have not tracked down yet. Just 15 compilation errors to go. After that, I guess linking will be a nightmare. Stay tuned.