I do something similar to this for projects I write that have to compile under windows (MSVC or nmake). However, instead of this approach:
} Instead of touching the Unix config.h file, a dedicated winconfig.h file } is introduced, and all the instances of: } } #ifdef HAVE_CONFIG_H } #include "config.h" } #endif } } are replaced with: } } #include "sysconfig.h" which is prety invasive, I do the following: create a windows directory, and create a version of config.h in the windows directory that is basically manually set up (like this patch does). Then, when compiling under windows, I just add -Iwindows to the compile line. This should result in the windows config.h being preferred over the top-level config.h. I don't see any reason not to do that, though it'll be work to keep the windows config.h manually synced with the unix config as changes are made to autoconf.ac. But I believe such changes are pretty rare at this point, so maybe it's a good trade-off. As for adding in a windows-specific Makefile (the second patch), I believe the pcre path is to use cmake rather than nmake, so I don't think this adds very much. (And maybe cmake automatically makes a config.h? What do windows developers do nowadays?) What would be more useful I think, if we don't already have it, would be a .sln and .vcproj files, for building under MSVC. But I don't actually develop in windows, so I don't know. Come to think of it, I'm probably not the right person to ask... craig -- ## List details at http://lists.exim.org/mailman/listinfo/pcre-dev
