So I played around with getting HTTPD to build on a windows machine today, using only the freely available "Express" version of Visual C++ that Microsoft released a little while back. It works, basically, but it's not nearly as easy as it should be, for a few reasons.
The major problems is that the conversion from the existing .dsp files over to VS.Net .sln and .vcproj files doesn't seem to work perfectly. Specifically, the libs that various targets are linked against don't seem to get migrated perfectly, so you have to go add a few .libs to libapr, libhttpd, a bunch of the command line tools, the win32 specific programs, and probably some more places I can't recall. Aside from this hurdle, the major problem with getting this stuff to build was simply that the Makefile.win targets describe in the build instructions include targets that run _build, which tries to run visual studio using the vc6 (I think) command line tool, which doesn't work with newer visual studio versions. It's possible to work around this by running the build by hand, then calling _install directly to build the dist tree, but it's a bit of a pain. I didn't actually go so far as to try building the APR tests, but I imagine they'd probably suffer similar problems to the httpd command line tools. So I guess what I'm asking is has anyone else spent any time working with these compilers? Is there any way we can make the use of them easier? I'd love for it to be a reasonably well defined set of steps for an APR or HTTPD developer to actually get things running on Win32, and if those instructions start with "go download this free thing from microsoft" as opposed to "go shell out a few hundred bucks for visual studio" it'll probably encourage people to actually do some work on the win32 code, which is a bit underloved lately IMO. If there isn't an easy way we can make our current system of .dsp files convert easily into VC.Net Express projects, then I'm curious if we couldn't start thinking about either maintaining parrallel build files for newer Visual Studio versions, or even better just switching to it as the default on win32. I'm sure that I recall various issues that make it desirable to use earlier versions of visual studio, but are these issues really insurmountable? -garrett